| +Home + | ++Documentation + | ++Mailing lists + | +
| +Help + | ++Download + | ++Developers + | +
| +Overview + |
| +Home + |
| +Features + |
| +Logos and Papers + |
| +Mailman in Use + |
| +Previous Releases + |
| +Bugs and Patches + |
| +Mirrors + |
| + |
| +Email Us + |
| +mailman-users@python.org + |
| + + |
+ |
| + + |
| +© 1998-2002 +Free Software Foundation, Inc. Verbatim copying and distribution of this +entire article is permitted in any medium, provided this notice is preserved. + + |
+See also the Mailman +FAQ Wizard for more information. + +
Mailman 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 described in RFC 2369 and are added by Mailman
+ for the long-term benefit of end-users. While discouraged, the
+ list admin can disable these via the General Options page. See
+ also README.USERAGENT for more information.
+
Q. Can I put the user's address in the footer that Mailman adds to
+ each message?
+
+
A. Yes, in Mailman 2.1. The site admin needs to enable
+ personalization by setting the following variables in the mm_cfg.py
+ file:
+
VERP_PASSWORD_REMINDERS = 1 + VERP_PERSONALIZED_DELIVERIES = 1 + VERP_DELIVERY_INTERVAL = 1 + VERP_CONFIRMATIONS = 1 +
Once this is done, list admins can enable personalization for + regular delivery members (digest deliveries can't be + personalized currently). A personalized list can include the + user's address in the footer. +
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 has this feature built-in. See the Content Filtering
+ Options page in the admin interface.
+
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. What should I check periodically?
+
+
A. Many of the scripts have their standard error logged to
+ $prefix/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.
+
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. 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:
+
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: +
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. +
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. :) +
+