mlm-command Docs for Sysadmins

Installation

If you're a Web (or mail) administrator who's installing mlm-command on your site, you don't need to do very much to make it work. Steps are as follows:

1. Copy or move the script to your cgi-bin directory and ensure that it has the correct ownerships and permissions to run properly.
2. Make sure the first line points to the correct location of Perl on your system -- probably #!/usr/local/bin/perl if it isn't the default value of #!/usr/bin/perl.
3. Scroll forward past the comments and documentation, and set the three security values (discussed below).
4. Edit $MailProg to make sure it points to the proper location of sendmail on your system. If you run sendmail, then you probably want /usr/bin/sendmail or /usr/lib/sendmail. If you run qmail, then /var/qmail/bin/sendmail should work. If you run some other mailer, then you essentially want some executable that will mimic the behavior of "sendmail -t": something that will read a mail message from STDIN. (If the system you're using needs a different command-line switch than '-t', change $MailOpts accordingly.)
5. If necessary, change $LocalAdmin to your username on this system, or to some local username or alias that will reach you (probably webmaster, postmaster, root, or something similar).
6. Test it and make sure it works. Problems? Contact kmactane@GothPunk.com.

Success? In that case, it would be nice of you to contact kmactane@GothPunk.com and let him (me) know it worked. You should probably also give your users a copy of the docs at http://www.GothPunk.com/~kmactane/software/mlm-command/commands.html, or the URL pointing to them, so that they can write HTML forms that use the script's features.

Security Considerations

mlm-command has not been subjected to any formal security audit, but it was written with at least some level of security in mind. (If you'd like to do a security audit on it, feel free! You've got the code. Please send any results to kmactane@GothPunk.com.)

mlm-command performs only one shell escape: date +'%a, %d %b %Y %T %z' (to get the date in RFC822 format). It also opens a pipe to $MailProg $MailOpts in order to send mail. Neither of these operations uses any user-supplied input. Potential buffer overflows should be handled by Perl's memory management. So installation of mlm-command shouldn't allow any nasty "skript kiddiez" to get root on your system.

In actual practice, the major security considerations appear to be not so much with buffer overflows and the like, but rather with potential misuses of the script's normal functionality -- people subscribing other people to (or removing them from) mailing lists without their consent. (It should be noted that this can be done already by simply sending the commands direct to the MLM; mlm-command simply serves as an intermediary that makes sending the commands easier.)

However, mlm-command does provide the UserConfirmMail setting as a hedge against this, as well as two other options to restrict its use. These options are all hard-coded into the script, and hence may easily be made secure against tampering by unauthorized local users simply by setting the script's permissions accordingly.

Hard-Coded Security Values

This script allows three security settings. These are hard-coded in the script, and can be set by site administrators.

In all cases involving the ForceLocal... variables, the "local" server name is acquired from the SERVER_NAME environment variable (passed to the script by the HTTP daemon); the referring server name is similarly derived from the HTTP_REFERER environment variable.

• ForceLocalReferrer: if this variable is non-zero, the script will return an error if the referring page is not on the same host as the script itself. The default value is zero, allowing the script to be invoked by any HTML page anywhere on the World Wide Web. While this is highly convenient, allowing easy access by authorized personnel and HTML forms from remote sites, it can also allow unauthorized access from remote sites.
• ForceLocalList: if this variable is non-zero, the script will will return an error if the list to affect is not on the same host as the script. By default, this value is set to zero, allowing a copy of mlm-command on any Web server to affect mailing lists hosted anywhere on the Internet. You probably don't mind if your own users (with Web pages hosted on your server) use your script to affect mailing lists elsewhere in the world, but the option to disallow it is included.
• UserConfirmMail: if this variable is non-zero, the script will send a plain-English email to EmailAddress as well as an email to the MLM that manages ListAddress. If there is a UserConfirmMail control in the referring form, its value will override the hard-coded value in the script, unless the script value is 1. If the script value is 1, the script will always send a confirming mail to the user, regardless of form input. This is a useful security device to inform people when their list subscriptions are being altered, but it can also be an inbox-cluttering annoyance.

In general, the bigger and more trafficked your site is, the more strongly you should lean toward setting UserConfirmMail to a non-zero or 1 value.

Portability Considerations

mlm-command was developed and tested on Linux, and primarily Red Hat Linux, systems, generally using Daniel J. Bernstein's Qmail as the mail transport agent, and all using the Apache Web server. It has not been tested on Postfix, Exim, or other MTAs, and information about how well it can integrate with them is heartily solicited. It also has not been tested with other Web servers such as NCSA, CERN, Roxen, Zeus, or whatnot.

Web Server Integration

As long as your Web server follows common CGI usage, passing the following environment variables, mlm-command should have no quarrels with the server software.

• REQUEST_METHOD *
• CONTENT_LENGTH *
• QUERY_STRING *
• SERVER_NAME *
• HTTP_REFERER
• DOCUMENT_ROOT

* = Required by CGI specification.

If your server doesn't supply HTTP_REFERER or DOCUMENT_ROOT, mlm-command is likely to freak out in strange ways.

Mail Transfer Agent Integration

If your MTA has, like Qmail, some sort of "hook" that can accept mail piped in on STDIN, including headers, then mlm-command should be able to send mail through it. It's not a requirement that the MTA not prepend its own headers to the piped input; indeed, that's expected.

If your MTA requires that some kind of gymnastics be done to set the SMTP envelope header information (such as setting environment variables for RCPT TO and MAIL FROM), then mlm-command should be able to interface with it with only minimal hacking, right before each instance of 'open MAIL'.

Operating System Integration

This is where things get complicated. If you use some fairly non-Linux-ish flavor of Unix, you may run into problems. Solaris and other strongly SysV-ish flavors keep their sendmail executable, if any, in odd places like /usr/ucb/lib. However, it's fairly simple to set the $MailProg variable to whatever path you need, including using /bin/mail or its equivalent, with appropriate flags.

Of perhaps greater difficulty is the reliance on date(1) to yield the RFC822 date. I didn't have a non-GNU version of date(1) around to test with, and I may have relied on some GNU date format features. If so, mlm-command may behave oddly or even be non-functional on systems with a non-GNU date(1). If this causes troubles, it will be fixed in a later release.

Questions? Comments? Suggestions for future features? Send 'em all to kmactane@GothPunk.com.

Home  |  Command Reference  |  DisplayFile Tokens  |  User Installation