diff options
Diffstat (limited to 'FAQ')
| -rw-r--r-- | FAQ | 394 |
1 files changed, 394 insertions, 0 deletions
@@ -0,0 +1,394 @@ +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 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: + + * remove $prefix/archives/private/<listname> + * edit $prefix/archives/private/<listname>.mbox/<listname>.mbox [optional] + * run $prefix/bin/arch <listname> + +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: |