Mailman - The GNU Mailing List Management System Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA Note: We're migrating the FAQ to an on-line interactive system called "FAQ Wizard". To see the Mailman FAQ Wizard in action, go to http://www.python.org/cgi-bin/faqw-mm.py FREQUENTLY ASKED QUESTIONS Q. How do you spell this program? A. You spell it "Mailman", with a leading capital "M" and a lowercase second "m". It is incorrect to spell it "MailMan" (i.e. you should not use StudlyCaps). Q. I'm getting really terrible performance for outgoing messages. It seems that if the MTA has trouble resolving DNS for any recipients, qrunner just gets really slow clearing the queue. Any ideas? A. What's likely happening is that your MTA is doing DNS resolution on recipients for messages delivered locally (i.e. from Mailman to your MTA via SMTPDirect.py). This is a Bad Thing. You need to turn off synchronous DNS resolution for messages originating from the local host. In Exim, the value to edit is receiver_verify_hosts. See README.EXIM for details. Other MTAs have (of course) different parameters and defaults that control this. First check the README file for your MTA and then consult your MTA's own documentation. Q. My list members are complaining about Mailman's List-* headers! What can I do about this? A. These headers are added by Mailman for the long-term benefit of end-users. Mailman is compliant with RFC 2369, which is where these headers are defined. See the file README.USERAGENT for hints on what to tell your end users. Q. Can I put the user's address in the footer that Mailman adds to each message? A. No. The reason is that, for efficiency, Mailman batches together message delivery for many users at once. Putting the user's address in the footer would require Mailman to craft a unique message for each recipient, and this would likely unacceptably bog down your system. Some MTAs may provide may provide the ability to accomplish this, using a technique akin to VERP (variable envelope return path). You'll need to investigate the configuration options of your MTA for details. Q. My users hate HTML in their email and for security reasons, I want to strip out all MIME attachments. How can I do this? A. Mailman 2.1 will probably have this feature built-in, but for now you can use add-on tools such as demime or stripmime. More information on these tools can be found at: (Stripmime) http://www.phred.org/~alex/stripmime.html (Demime) http://scifi.squawk.com/demime.html Q. What if I get "document contains no data" from the web server, or mail isn't getting delivered, or I see "Premature end of script headers" or "Mailman CGI error!!!" A. The most likely cause of this is that the GID that is compiled into the C wrappers does not match the GID that your Web server invokes CGI scripts with. Note that a similar error could occur if your mail system invokes filter programs under a GID that does not match the one compiled into the C mail wrapper. To fix this you will need to re-configure Mailman using the --with-cgi-gid and --with-mail-gid options. See the INSTALL file for details. These errors are logged to syslog and they do not show up in the Mailman log files. Problems with the CGI wrapper do get reported in the web browser though (unless STEALTH_MODE is enabled), and include the expected GID, so that should help a lot. You may want to have syslog running and configured to log the mail.error log class somewhere; on Solaris systems, the line mail.debug /var/log/syslog causes the messages to go to them in /var/log/syslog, for example. (The distributed syslog.conf forwards the message to the loghost, when present. See the syslog man page for more details.) If your system is set like this, and you get a failure trying to visit the mailman/listinfo web page, and it's due to a UID or GID mismatch, then you should get an entry at the end of /var/log/syslog identifying the expected and received values. If you are not getting any log messages in syslog, or in Mailman's own log files, but messages are still not being delivered, then it is likely that qrunner is not running (qrunner is the process that handles all mail in the system). In Mailman 2.0, qrunner was invoked from cron so make sure your crontab entries for the `mailman' user have been installed. In Mailman 2.1, qrunner is started with the bin/mailmanctl script, which can be invoked manually, or merged with your OS's init scripts. Q. Why do my web pages hang? A. CERN Web servers might leave Python processes running, and in some cases might hang the CGI completely. In that case, switch to Apache. It is also possible that you have stale locks. Mailman tries to be very careful about the lock files it creates to ensure the integrity of its databases, but sometimes system faults can cause stale locks to persist. Look in $prefix/locks for any stale list locks and remove them (you can determine if they're stale by getting the pid from the file contents and using ps to see if those processes are still running or not). Q. What should I check periodically? A. Many of the scripts have their standard error logged to ~mailman/logs/error, and some of the modules write caught errors there, as well, so you should check there at least occasionally to look for bugs in the code and problems in your setup. One thing that is reported in logs/error is syntax errors, but any of these should have been caught in the installation phase, which byte-compiles all .py files in the distribution. There may be syntax errors lurking if you hacked the code, or in the scripts that are not modules. You can always use the Python module `compile' or `compileall' to force byte compilation of a file, or just fire up the Python interpreter and try importing the module. You may want to periodically check the other log files in the logs/ directory, perhaps occasionally rotating them with something like the Linux logrotate script. Q. Why doesn't the archive link work? A. Have any messages been posted to the list? This is a known buglet; the archive link doesn't work until at least one message has been posted. Q. Okay, the archive link works, but I can't access the public archives. Why? A. If you are using Apache, you must make sure that FollowSymLinks is enabled for the path to the public archives. Note that the actual archives always reside in the private tree, and only when archives are public, is the symlink followed. See this archive message for more details: http://mail.python.org/pipermail/mailman-users/1998-November/000150.html Q. Still having problems? Running QMail? A. Make sure that you are using "preline" before calling the "mailman" wrapper: |preline /home/mailman/mail/mailman post listname "preline" adds a Unix-style "From " header which the archiver requires. You can fix the archive mbox files by adding: From somebody Mon Oct 9 12:27:34 MDT 2000 before every message and re-running the archive command "bin/arch listname". The archives should now exist. See README.QMAIL for more information. Q. Still having problems? Running on GNU/Linux? A. See the README.LINUX file. Q. I want to get rid of some messages in my archive. How do I do this? A. David Rocher posts the following recipe: * remove $prefix/archives/private/ * edit $prefix/archives/private/.mbox/.mbox [optional] * run $prefix/bin/arch Q. I set member_posting_only to yes because I want to limit posts to members only, however it seems like all messages coming from members are held for approval. Why? A. There appears to be a problem on some systems where the envelope sender (e.g. the Unix "From " line) is set incorrectly. This will cause a negative match when checking to see if the sender is a member of the list. Until 1.0b12, Mailman defaulted to using the envelope sender before the sender (i.e. "From:" header) because the former is set by the SMTP agent while the latter is easily spoofable by the end user. [ The possible causes for envelope sender munging taking place are many, but the "owner-alias" sendmail feature probably deserves special mention: If mail arrives for list "foo", and there is an alias entry for "owner-foo" as well, the envelope sender of the message will be changed to the single-level expansion of the "owner-foo" alias. Code has been included in post-1.0rc2 Mailman releases to try working around the problem this (unconfigurable) sendmail feature constitutes. Prior to this, some people worked around the problem by not including the suggested "owner-LISTNAME" alias entries for Mailman lists in their alias files. ] However, if you are having this problem, you may opt to favor the From: header over the envelope sender. Do this by adding the following line to your mm_cfg.py file: USE_ENVELOPE_SENDER=0 if you want (arguably) more security, add this to your mm_cfg.py file: USE_ENVELOPE_SENDER=1 However, read the comments about this variable in the Defaults.py file for a full discussion of the issues. By default, Mailman 2.0 relies on the From: header for doing address matching. Q. How secure are the authentication mechanisms used in Mailman's web interface? A. If your Mailman installation run on an SSL-enabled web server (i.e. you access the Mailman web pages with "https://..." URLs), you should be as safe as SSL itself is. However, most Mailman installation run under standard, encryption-unaware servers. There's nothing wrong with that for most applications, but a sufficiently determined cracker *could* get unauthorized access by: * Packet sniffing: The password used to do the initial authentication for any non-public Mailman page is sent as clear text over the net. If you consider this to be a big problem, you really should use an SSL-enabled server. * Stealing a valid cookie: After successful password authentication, Mailman sends a "cookie" back to the user's browser. This cookie will be used for "automatic" authentication when browsing further within the list's protected pages. Mailman employs "session cookies" which are set until you quit your browser or explicitly log out. Gaining access to the user's cookie (e.g. by being able to read the user's browser cookie database, or by means of packet sniffing, or maybe even by some broken browser offering all it's cookies to any and all sites the user accesses), and at the same time being able to fulfill the other criteria for using the cookie could result in unauthorized access. Note that this problem is more easily exploited when users browse the web via proxies -- in that case, the cookie would be valid for any connections made through that proxy, and not just for connections made from the particular machine the user happens to be accessing the proxy from. * Getting access to the user's terminal: This is really just another kind of cookie stealing. The short cookie expiration time is supposed to help defeat this problem. It can be considered the price to pay for the convenience of not having to type the password in every time. Q. I want to backup my lists. What do I need to save? A. See this FAQ wizard entry: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.006.htp Q. How do I rename a list? A. Renaming a list is currently a bit of a pain to do completely correctly, especially if you want to make sure that the old list contacts are automatically forwarded to the new list. This ought to be easier. :( The biggest problem you have is how to stop mail and web traffic to your list during the transition, and what to do about any mail undelivered to the old list after the move. I don't think there are any foolproof steps, but here's how you can reduce the risk: - Temporarily disable qrunner. To do this, you need to edit the user `mailman's crontab entry. Execute the following command, commenting out the qrunner line when you're dropped into your editor. Then save the file and quit the editor. % crontab -u mailman -e - Turn off your mail server. This is mostly harmless since remote MTAs will just keep retrying until you turn it back on, and it's not going to be off for very long. - Next turn off your web server if possible. This of course means your entire site will be off-line while you make the switch and this may not be acceptable to you. The next best suggestion is to set up your permanent redirects now for the list you're moving. This means that anybody looking for the list under its old name will be redirected to the new name, but they'll get errors until you've completed the move. Let's say the old name is "oldname" and the new name is "newname". Here are some Apache directives that will do the trick, though YMMV: RedirectMatch permanent /mailman/(.*)/oldname(.*) http://www.dom.ain/mailman/$1/newname$2 RedirectMatch permanent /pipermail/oldname(.*) http://www.dom.ain/pipermail/newname$1 Add these to your httpd.conf file and restart Apache. - Now cd to the directory where you've installed Mailman. Let's say it's /usr/local/mailman: % cd /usr/local/mailman and cd to the `lists' subdirectory: % cd lists You should now see the directory `oldname'. Move this to `newname': % mv oldname newname - Now cd to the private archives directory: % cd ../archives/private You will need to move the oldname's .mbox directory, and the .mbox file within that directory. Don't worry about the public archives; the next few steps will take care of them without requiring you to fiddle around in the file system: % mv oldname.mbox newname.mbox % mv newname.mbox/oldname.mbox newname.mbox/newname.mbox - You now need to run the `bin/move_list' script to update some of the internal archiver paths. IMPORTANT: Skip this step if you are using Mailman 2.1! % cd ../.. % bin/move_list newname - You should now regenerate the public archives: % bin/arch newname - You'll likely need to change some of your list's configuration options, especially if you want to accept postings addressed to the old list on the new list. Visit the admin interface for your new list: o Go to the General options o Change the "real_name" option to reflect the new list's name, e.g. "Newname" o Change the subject prefix to reflect the new list's name, e.g. "[Newname] " (yes, that's a trailing space character). o Optionally, update other configuration fields like info, description, or welcome_msg. YMMV. o Save your changes o Go to the Privacy options o Add the old list's address to acceptable_aliases. E.g. "oldname@dom.ain". This way, (after the /etc/aliases changes described below) messages posted to the old list will not be held by the new list for "implicit destination" approval. o Save your changes - Now you want to update your /etc/aliases file to include the aliases for the new list, and forwards for the old list to the new list. Note that these instructions are for Sendmail style alias files, adjust to the specifics of how your MTA is set up. o Find the lines defining the aliases for your old list's name o Copy and paste them just below the originals. o Change all the references of "oldname" to "newname" in the pasted stanza. o Now change the targets of the original aliases to forward to the new aliases. When you're done, you will end up with /etc/aliases entries like the following (YMMV): XXX This needs updating for MM2.1! # Forward the oldname list to the newname list oldname: newname@dom.ain oldname-request: newname-request@dom.ain oldname-admin: newname-admin@dom.ain oldname-owner: newname-owner@dom.ain newname: "|/usr/local/mailman/mail/mailman post newname" newname-admin: "|/usr/local/mailman/mail/mailman mailowner newname" newname-request: "|/usr/local/mailman/mail/mailman mailcmd newname" newname-owner: newname-admin o Run newaliases - Before you restart everything, you want to make one last check. You're looking for files in the qfiles/ directory that may have been addressed to the old list but weren't delivered before you renamed the list. Do something like the following: % cd /usr/local/mailman/qfiles % grep oldname *.msg If you get no hits, skip to the next step, you've got nothing to worry about. If you did get hits, then things get complicated. I warn you that the rest of this step is untested. :( For each of the .msg files that were destined for the old list, you need to change the corresponding .db file. Unfortunately there's no easy way to do this. Anyway... Save the following Python code in a file called 'hackdb.py': -------------------------hackdb.py import sys import marshal fp = open(sys.argv[1]) d = marshal.load(fp) fp.close() d['listname'] = sys.argv[2] fp = open(sys.argv[1], 'w') marshal.dump(d, fp) fp.close() ------------------------- And then for each file that matched your grep above, do the following: % python hackdb.py reallylonghexfilenamematch1.db newname - It's now safe to turn your MTA back on. - Turn your qrunner back on by running % crontab -u mailman -e again and this time uncommenting the qrunner line. Save the file and quit your editor. - Rejoice, you're done. Send $100,000 in shiny new pennies to the Mailman cabal as your downpayment toward making this easier for the next list you have to rename. :) Local Variables: mode: text indent-tabs-mode: nil End: