Introduction Usage System Requirements Installation Configuration Future Direction Licensing, FAQs, & Credits |
wrapper
program to enforce permissions and provide the
necessary uid/gid operation.
$homedir
and the /cgi-bin/
directory of the Web server is required.
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.
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.