[MajorCool]

MajorCool: A Web Interface To Majordomo

(This is a copy of the MajorCool master documentation set)
Introduction
Usage
System Requirements
Installation
Configuration
Future Direction
Licensing, FAQs, & Credits

Server Requirements

A Note About Web Server Security

Although the MajorCool CGI utilizes the 'POST' method to hide script arguments wherever possible, URL-based parameters are used in certain situations. If your server is configured to log full URL data, this could result in script arguments being written to the Web server access log. Someone with access to the local Web server logs would then have access to this info.

Some servers do not log complete URL data, and many that do can be disabled. Here's how one user (perry@ece.vill.edu) avoided the problem:

As far as Web server logging goes, that is not a problem with
MajorCool per se, and I've discovered that I can work around 
it in Apache by specifying a different LogFormat in httpd.conf:

  LogFormat "%h %l %v:%p %t \"- %U HTTP/1.x %{cipher}c %u\" %>s %b"

The default LogFormat for Apache is: "%h %l %u %t \"%r\" %>s %b"
Mine is hacked for SSL and virtual hosts, and also doesn't break 
the 'wwwstat' statistics reporting script, but the main thing is 
to replace %r with %U to just get the URL pathname and no GET 
arguments.

At last analysis, most MajorCool arguments passed as part of the URL could be considered relatively harmless, and if you run your Web server on a restricted-access machine you have even less to worry about. Noting the logging behavior here is done more as a courtesy than a warning.

Browser Requirements

Majordomo Requirements

This application was originally designed for Majordomo version 1.93, but it has since been enhanced to incorporate 1.94 features. Because MajorCool relies on the Majordomo config file API, list configuration differences between 1.93 and 1.94 are not a problem. For instance, users migrating from Majordomo 1.93 to 1.94 will notice that support for the new +confirm subscribe policy attribute requires no changes to MajorCool code. Similarly, no special modifications are required to make local keyword additions visible to the application.

Certain of these "local keywords" (ie, keywords not part of the standard Majordomo distribution) are specially designed for use by MajorCool and attempt to make list management a more pleasurable and/or efficient activity...

'owner' Keyword (Optional)

The "owner" keyword defines the e-mail address of the list-owner. The addition of this keyword to Majordomo is completely optional (modification details later). However, if detected, MajorCool will use the value of the "owner" variable to determine the reply address of administrative mail messages that are simulated and passed on to Majordomo. More importantly, the existence of the "owner" attribute opens the door for automatic alias generation.

In our configuration, a list is not active until "owner" is defined. Using this mechanism, our sendmail alias administration is completely hands free. Given a new list, users can set the ownership themselves (thus activating the -owner, -approval, -request, and -outgoing aliases) and, if necessary, can later reassign list responsibilities without administrative assistance.

If you choose not to implement the owner keyword, MajorCool will revert to using the owner-$list address for all operations performed during list configuration. Without the owner keyword, you do not have the potential for automatic alias generation or access to owner-specific functions such as the "show all owned lists" option of MajorCool.

'web_access' Keyword (Optional)

In a standard Majordomo installation, all lists are available to MajorCool (subject to advertise and password checks, of course). With the addition of the web_access keyword, list owners can control whether their list is made available to MajorCool's BROWSE and/or MODIFY modes. This is most useful to address list-owner concerns/fears about web accessibility without unduly preventing the rest of the lists at the site from reaping the rewards of improved usability.

Approval Queue (Optional)

Normally, messages sent to a mailing list that require "approval" are redirected to a moderator address. The moderator must then manipulate specific header information and send the message back to the list in order to "approve" it.

With an enhancement available for Majordomo (see patches in contrib/), the approval process can be modified to store a copy of the redirected mail on the list server (instead of, or in addition to, the copy sent to the moderator). MajorCool can then be used to manage this Approval Queue via the Web. By utilizing the Web-based approval process, problems caused by misbehaving mailers or incorrectly placed headers are eliminated.

The enhancement for Majordomo adds a bounce_action keyword to the list configuration file. This keyword can be set to mail the message to the moderator, store the file locally, or a combination of both actions. MajorCool can access any locally stored messages and approve them directly. If your host system is configured for bounce_action, MajorCool will automatically support the capability.


[Previous: Usage] [Next: Install] [Top: Intro] [Home] [Feedback]