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:
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.
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.
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.
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.
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.
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.
* = 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.
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'.
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