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 variable in the mm_cfg.py file:
-
OWNERS_CAN_ENABLE_PERSONALIZATION = Yes -
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. :) -
\ No newline at end of file -- cgit v1.2.3