diff options
Diffstat (limited to '')
| -rw-r--r-- | admin/www/faq.ht | 301 | ||||
| -rw-r--r-- | admin/www/faq.html | 433 |
2 files changed, 734 insertions, 0 deletions
diff --git a/admin/www/faq.ht b/admin/www/faq.ht new file mode 100644 index 00000000..2fd281d2 --- /dev/null +++ b/admin/www/faq.ht @@ -0,0 +1,301 @@ +Title: Mailman Frequently Asked Questions + +See also the <a href="http://www.python.org/cgi-bin/faqw-mm.py">Mailman +FAQ Wizard</a> for more information. + + <h3>Mailman Frequently Asked Questions</h3> + +<b> Q. How do you spell this program? + +</b><br> 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). +<p> <b> 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? + +</b><br> 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. +<p> 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. +<p> <b> Q. My list members are complaining about Mailman's List-* headers! + What can I do about this? + +</b><br> 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. +<p> <b> Q. Can I put the user's address in the footer that Mailman adds to + each message? + +</b><br> A. Yes, in Mailman 2.1. The site admin needs to enable + personalization by setting the following variables in the mm_cfg.py + file: +<p> VERP_PASSWORD_REMINDERS = 1 + VERP_PERSONALIZED_DELIVERIES = 1 + VERP_DELIVERY_INTERVAL = 1 + VERP_CONFIRMATIONS = 1 +<p> 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. +<p> <b> 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? + +</b><br> A. Mailman 2.1 has this feature built-in. See the Content Filtering + Options page in the admin interface. +<p> <b> 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!!!" + +</b><br> 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. +<p> 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. +<p> 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. +<p> You may want to have syslog running and configured to log the + mail.error log class somewhere; on Solaris systems, the line +<p> mail.debug /var/log/syslog +<p> 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.) +<p> 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. +<p> 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. +<p> <b> Q. What should I check periodically? + +</b><br> 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. +<p> 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. +<p> <b> Q. I can't access the public archives. Why? + +</b><br> 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: +<p> <a href="http://mail.python.org/pipermail/mailman-users/1998-November/000150.html">http://mail.python.org/pipermail/mailman-users/1998-November/000150.html</a> +<p> <b> Q. Still having problems? Running QMail? + +</b><br> A. Make sure that you are using "preline" before calling the "mailman" + wrapper: +<p> |preline /home/mailman/mail/mailman post listname +<p> "preline" adds a Unix-style "From " header which the archiver requires. + You can fix the archive mbox files by adding: +<p> From somebody Mon Oct 9 12:27:34 MDT 2000 +<p> before every message and re-running the archive command + "bin/arch listname". The archives should now exist. See README.QMAIL + for more information. +<p> <b> Q. Still having problems? Running on GNU/Linux? + +</b><br> A. See the README.LINUX file. +<p> <b> Q. I want to get rid of some messages in my archive. How do I do + this? + +</b><br> A. David Rocher posts the following recipe: +<p> <li> + remove $prefix/archives/private/<em>listname</em> +<li> + edit $prefix/archives/private/<em>listname</em>.mbox/<em>listname</em>.mbox [optional] +<li> + run $prefix/bin/arch <em>listname</em> +<p> <b> Q. How secure are the authentication mechanisms used in Mailman's web + interface? + +</b><br> 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. +<p> 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: +<p> <li> + 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. +<p> <li> + 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. +<p> 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. +<p> 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. +<p> <li> + 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. +<p> <b> Q. I want to backup my lists. What do I need to save? + +</b><br> A. See this FAQ wizard entry: + <a href="http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.006.htp">http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.006.htp</a> +<p> <b> Q. How do I rename a list? + +</b><br> 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. :( +<p> 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: +<p> - 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. +<p> % crontab -u mailman -e +<p> - 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. +<p> - 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. +<p> 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: +<p> RedirectMatch permanent /mailman/(.*)/oldname(.*) <a href="http://www.dom.ain/mailman/$1/newname$2">http://www.dom.ain/mailman/$1/newname$2</a> + RedirectMatch permanent /pipermail/oldname(.*) <a href="http://www.dom.ain/pipermail/newname$1">http://www.dom.ain/pipermail/newname$1</a> +<p> Add these to your httpd.conf file and restart Apache. +<p> - Now cd to the directory where you've installed Mailman. Let's + say it's /usr/local/mailman: +<p> % cd /usr/local/mailman +<p> and cd to the `lists' subdirectory: +<p> % cd lists +<p> You should now see the directory `oldname'. Move this to + `newname': +<p> % mv oldname newname +<p> - Now cd to the private archives directory: +<p> % cd ../archives/private +<p> 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: +<p> % mv oldname.mbox newname.mbox + % mv newname.mbox/oldname.mbox newname.mbox/newname.mbox +<p> - 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! +<p> % cd ../.. + % bin/move_list newname +<p> - You should now regenerate the public archives: +<p> % bin/arch newname +<p> - 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: +<p> o Go to the General options +<p> o Change the "real_name" option to reflect the new list's name, + e.g. "Newname" +<p> o Change the subject prefix to reflect the new list's name, + e.g. "[Newname] " (yes, that's a trailing space character). +<p> o Optionally, update other configuration fields like info, + description, or welcome_msg. YMMV. +<p> o Save your changes +<p> o Go to the Privacy options +<p> 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. +<p> o Save your changes +<p> - 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. +<p> o Find the lines defining the aliases for your old list's name +<p> o Copy and paste them just below the originals. +<p> o Change all the references of "oldname" to "newname" in the + pasted stanza. +<p> 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): +<p> XXX This needs updating for MM2.1! +<p> # 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 +<p> 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 +<p> o Run newaliases +<p> - 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: +<p> % cd /usr/local/mailman/qfiles + % grep oldname *.msg +<p> If you get no hits, skip to the next step, you've got nothing to + worry about. +<p> If you did get hits, then things get complicated. I warn you + that the rest of this step is untested. :( +<p> 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... +<p> Save the following Python code in a file called 'hackdb.py': +<p> -------------------------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() + ------------------------- +<p> And then for each file that matched your grep above, do the + following: +<p> % python hackdb.py reallylonghexfilenamematch1.db newname +<p> - It's now safe to turn your MTA back on. +<p> - Turn your qrunner back on by running +<p> % crontab -u mailman -e +<p> again and this time uncommenting the qrunner line. Save the file + and quit your editor. +<p> - 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. :) +<p> <p>
\ No newline at end of file diff --git a/admin/www/faq.html b/admin/www/faq.html new file mode 100644 index 00000000..60c0ec7e --- /dev/null +++ b/admin/www/faq.html @@ -0,0 +1,433 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> +<!-- THIS PAGE IS AUTOMATICALLY GENERATED. DO NOT EDIT. --> +<!-- Thu Dec 26 22:30:25 2002 --> +<!-- USING HT2HTML 2.0 --> +<!-- SEE http://ht2html.sf.net --> +<!-- User-specified headers: +Title: Mailman Frequently Asked Questions + +--> + +<head> +<title>Mailman Frequently Asked Questions</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> +<meta name="generator" content="HT2HTML/2.0"> +<style type="text/css"> +body { margin: 0px; } +</style> +</head> +<body bgcolor="#ffffff" text="#000000" + marginwidth="0" marginheight="0" + link="#0000bb" vlink="#551a8b" + alink="#ff0000"> +<!-- start of page table --> +<table width="100%" border="0" cellspacing="0" cellpadding="0"> +<!-- start of banner row --> +<tr> +<!-- start of corner cells --> +<td width="150" valign="middle" bgcolor="white" class="corner"> + +<center> + <a href="./index.html"> + <img border=0 src="./images/logo-70.jpg"></a></center> </td> +<td width="15" bgcolor="#eecfa1"> </td><!--spacer--> +<!-- end of corner cells --> +<!-- start of banner --> +<td width="90%" bgcolor="#eecfa1" class="banner"> +<!-- start of site links table --> +<table width="100%" border="0" +CELLSPACING=0 CELLPADDING=0 + bgcolor="#ffffff"> +<tr> + <td bgcolor="#eecfa1"> +<a href="./index.html">Home</a> + </td> + <td bgcolor="#eecfa1"> +<a href="./docs.html">Documentation</a> + </td> + <td bgcolor="#eecfa1"> +<a href="./lists.html">Mailing lists</a> + </td> +</tr><tr> + <td bgcolor="#eecfa1"> +<a href="./help.html">Help</a> + </td> + <td bgcolor="#eecfa1"> +<a href="./download.html">Download</a> + </td> + <td bgcolor="#eecfa1"> +<a href="./devs.html">Developers</a> + </td> +</tr> +</table><!-- end of site links table --> + +</td><!-- end of banner --> +</tr><!-- end of banner row --> +<tr><!-- start of sidebar/body row --> +<!-- start of sidebar cells --> +<td width="150" valign="top" bgcolor="#eecfa1" class="sidebar"> +<!-- start of sidebar table --> +<table width="100%" border="0" cellspacing="0" cellpadding="3" + bgcolor="#ffffff"> +<tr><td bgcolor="#36648b"><b><font color="#ffffff"> +Overview +</font></b></td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="index.html">Home</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="features.html">Features</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="otherstuff.html">Logos and Papers</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="inthenews.html">Mailman in Use</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="prev.html">Previous Releases</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="bugs.html">Bugs and Patches</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="mirrors.html">Mirrors</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<tr><td bgcolor="#36648b"><b><font color="#ffffff"> +Email Us +</font></b></td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="mailto:mailman-users@python.org">mailman-users@python.org</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> + +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="http://www.python.org/"><img border=0 + src="./images/PythonPoweredSmall.png" + ></a> <a href="http://sourceforge.net"><img + src="http://sourceforge.net/sflogo.php?group_id=103" + width="88" height="31" border="0" + alt="SourceForge Logo"></a> +</td></tr> +<tr><td bgcolor="#eecfa1"> + +</td></tr> +<tr><td bgcolor="#eecfa1"> +© 1998-2002 +Free Software Foundation, Inc. Verbatim copying and distribution of this +entire article is permitted in any medium, provided this notice is preserved. + +</td></tr> +</table><!-- end of sidebar table --> + +</td> +<td width="15"> </td><!--spacer--> +<!-- end of sidebar cell --> +<!-- start of body cell --> +<td valign="top" width="90%" class="body"><br> +See also the <a href="http://www.python.org/cgi-bin/faqw-mm.py">Mailman +FAQ Wizard</a> for more information. + + <h3>Mailman Frequently Asked Questions</h3> + +<b> Q. How do you spell this program? + +</b><br> 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). +<p> <b> 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? + +</b><br> 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. +<p> 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. +<p> <b> Q. My list members are complaining about Mailman's List-* headers! + What can I do about this? + +</b><br> 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. +<p> <b> Q. Can I put the user's address in the footer that Mailman adds to + each message? + +</b><br> A. Yes, in Mailman 2.1. The site admin needs to enable + personalization by setting the following variables in the mm_cfg.py + file: +<p> VERP_PASSWORD_REMINDERS = 1 + VERP_PERSONALIZED_DELIVERIES = 1 + VERP_DELIVERY_INTERVAL = 1 + VERP_CONFIRMATIONS = 1 +<p> 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. +<p> <b> 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? + +</b><br> A. Mailman 2.1 has this feature built-in. See the Content Filtering + Options page in the admin interface. +<p> <b> 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!!!" + +</b><br> 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. +<p> 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. +<p> 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. +<p> You may want to have syslog running and configured to log the + mail.error log class somewhere; on Solaris systems, the line +<p> mail.debug /var/log/syslog +<p> 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.) +<p> 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. +<p> 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. +<p> <b> Q. What should I check periodically? + +</b><br> 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. +<p> 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. +<p> <b> Q. I can't access the public archives. Why? + +</b><br> 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: +<p> <a href="http://mail.python.org/pipermail/mailman-users/1998-November/000150.html">http://mail.python.org/pipermail/mailman-users/1998-November/000150.html</a> +<p> <b> Q. Still having problems? Running QMail? + +</b><br> A. Make sure that you are using "preline" before calling the "mailman" + wrapper: +<p> |preline /home/mailman/mail/mailman post listname +<p> "preline" adds a Unix-style "From " header which the archiver requires. + You can fix the archive mbox files by adding: +<p> From somebody Mon Oct 9 12:27:34 MDT 2000 +<p> before every message and re-running the archive command + "bin/arch listname". The archives should now exist. See README.QMAIL + for more information. +<p> <b> Q. Still having problems? Running on GNU/Linux? + +</b><br> A. See the README.LINUX file. +<p> <b> Q. I want to get rid of some messages in my archive. How do I do + this? + +</b><br> A. David Rocher posts the following recipe: +<p> <li> + remove $prefix/archives/private/<em>listname</em> +<li> + edit $prefix/archives/private/<em>listname</em>.mbox/<em>listname</em>.mbox [optional] +<li> + run $prefix/bin/arch <em>listname</em> +<p> <b> Q. How secure are the authentication mechanisms used in Mailman's web + interface? + +</b><br> 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. +<p> 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: +<p> <li> + 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. +<p> <li> + 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. +<p> 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. +<p> 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. +<p> <li> + 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. +<p> <b> Q. I want to backup my lists. What do I need to save? + +</b><br> A. See this FAQ wizard entry: + <a href="http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.006.htp">http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.006.htp</a> +<p> <b> Q. How do I rename a list? + +</b><br> 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. :( +<p> 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: +<p> - 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. +<p> % crontab -u mailman -e +<p> - 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. +<p> - 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. +<p> 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: +<p> RedirectMatch permanent /mailman/(.*)/oldname(.*) <a href="http://www.dom.ain/mailman/$1/newname$2">http://www.dom.ain/mailman/$1/newname$2</a> + RedirectMatch permanent /pipermail/oldname(.*) <a href="http://www.dom.ain/pipermail/newname$1">http://www.dom.ain/pipermail/newname$1</a> +<p> Add these to your httpd.conf file and restart Apache. +<p> - Now cd to the directory where you've installed Mailman. Let's + say it's /usr/local/mailman: +<p> % cd /usr/local/mailman +<p> and cd to the `lists' subdirectory: +<p> % cd lists +<p> You should now see the directory `oldname'. Move this to + `newname': +<p> % mv oldname newname +<p> - Now cd to the private archives directory: +<p> % cd ../archives/private +<p> 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: +<p> % mv oldname.mbox newname.mbox + % mv newname.mbox/oldname.mbox newname.mbox/newname.mbox +<p> - 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! +<p> % cd ../.. + % bin/move_list newname +<p> - You should now regenerate the public archives: +<p> % bin/arch newname +<p> - 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: +<p> o Go to the General options +<p> o Change the "real_name" option to reflect the new list's name, + e.g. "Newname" +<p> o Change the subject prefix to reflect the new list's name, + e.g. "[Newname] " (yes, that's a trailing space character). +<p> o Optionally, update other configuration fields like info, + description, or welcome_msg. YMMV. +<p> o Save your changes +<p> o Go to the Privacy options +<p> 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. +<p> o Save your changes +<p> - 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. +<p> o Find the lines defining the aliases for your old list's name +<p> o Copy and paste them just below the originals. +<p> o Change all the references of "oldname" to "newname" in the + pasted stanza. +<p> 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): +<p> XXX This needs updating for MM2.1! +<p> # 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 +<p> 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 +<p> o Run newaliases +<p> - 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: +<p> % cd /usr/local/mailman/qfiles + % grep oldname *.msg +<p> If you get no hits, skip to the next step, you've got nothing to + worry about. +<p> If you did get hits, then things get complicated. I warn you + that the rest of this step is untested. :( +<p> 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... +<p> Save the following Python code in a file called 'hackdb.py': +<p> -------------------------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() + ------------------------- +<p> And then for each file that matched your grep above, do the + following: +<p> % python hackdb.py reallylonghexfilenamematch1.db newname +<p> - It's now safe to turn your MTA back on. +<p> - Turn your qrunner back on by running +<p> % crontab -u mailman -e +<p> again and this time uncommenting the qrunner line. Save the file + and quit your editor. +<p> - 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. :) +<p> <p> +</td><!-- end of body cell --> +</tr><!-- end of sidebar/body row --> +</table><!-- end of page table --> +</body></html> |