This commit was manufactured by cvs2svn to create branch

'Release_2_1-maint'.

1 files changed, 301 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