Move FAQ

1 files changed, 0 insertions, 389 deletions

diff --git a/docs/FAQ.txt b/docs/FAQ.txt
deleted file mode 100644
index db38bedc0..000000000
--- a/docs/FAQ.txt
+++ /dev/null
@@ -1,389 +0,0 @@
-Mailman - The GNU Mailing List Management System
-Copyright (C) 1998-2007 by the Free Software Foundation, Inc.
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 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 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:
-
-   * 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: