Remove some documents that are either no longer appropriate, or now live in

the mailman-administrivia package.

Update the README.txt and NEWS.txt files for the first alpha release, and add
an ALPHA.txt file to describe what little you can do with the alpha release
<wink>.

8 files changed, 0 insertions, 1314 deletions

diff --git a/docs/readmes/FAQ.txt b/docs/readmes/FAQ.txt
deleted file mode 100644
index db38bedc0..000000000
--- a/docs/readmes/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:
diff --git a/docs/readmes/INSTALL.txt b/docs/readmes/INSTALL.txt
deleted file mode 100644
index c88ad05fc..000000000
--- a/docs/readmes/INSTALL.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Mailman - The GNU Mailing List Management System
-Copyright (C) 1998-2007 Free Software Foundation, Inc.
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
-The installation and upgrading instructions are now completely contained in
-the Mailman Installation Guide.  Web, PostScript, PDF, and plaintext formats
-for this guide are available both within this source distribution and online.
-
-All manuals within this source distribution are provided in the admin/www
-directory:
-
-    HTML        : admin/www/mailman-install/index.html
-    PostScript  : admin/www/mailman-install.ps
-    PDF         : admin/www/mailman-install.pdf
-    plain text  : admin/www/mailman-install.txt
-
-Or go online at http://www.list.org/site.html to find the online installation
-guide.
-
-
-
-Local Variables:
-mode: indented-text
-indent-tabs-mode: nil
-End:
diff --git a/docs/readmes/README-I18N.en b/docs/readmes/README-I18N.en
deleted file mode 100644
index f6c2c4a95..000000000
--- a/docs/readmes/README-I18N.en
+++ /dev/null
@@ -1,213 +0,0 @@
-Mailman - The GNU Mailing List Management System
-Copyright (C) 2001-2007 by the Free Software Foundation, Inc.
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
-
-INTERNATIONALIZATION
-
-    Mailman 2.1 is multilingual.  By default it supports English, but
-    additional languages may also be available.  If the language you
-    want to add is already supported by Mailman, then getting all your
-    lists to also support that language is fairly easy.  You just need
-    to go to the administrative web pages, click on the "Languages"
-    category, and select the languages you want your list to support.
-
-    If the language you want to use has not been previously
-    translated, or you don't know where to find the language pack for
-    your language, read the section below or contact the Mailman
-    internationalization mailing list mailman-i18n@python.org.
-
-
-ADDING NEW TRANSLATIONS
-
-    Suppose you want to add new translations for a previously
-    unsupported language, what steps would you need to take?
-
-    First, you should send a message to mailman-i18n@python.org to
-    make sure nobody has already created the translations for your
-    language.  In the example below, we're going to create a
-    translation for the mythical language "Fredonia" which has the
-    official language code of "xx".
-
-    You should see
-
-        http://www.list.org/i18n.html
-
-    for more information on internationalizing Mailman.  Also, Simone
-    Piunno -- who is the Italian translation champion -- has written
-    up some nice instructions, which are provided below.
-
-    In general you need to do two things to add translations for a
-    language in Mailman.  You need to translate the message catalog
-    and you need to translate the templates.
-
-    To translate the message catalog, grab the file
-    messages/mailman.pot and make a copy called mailman.po in the
-    subdirectory messages/xx/LC_MESSAGES.  Then you edit the file and
-    add the translations for each message identified in the catalog.
-    It will be very helpful to have a good tool, such as KDE's KBabel
-    tool, or po-mode for Emacs, for this part of the job.
-
-    Once you've added your translations, you can then run msgfmt over
-    your .po file to generate messages/xx/LC_MESSAGE/mailman.mo.  Run
-    "make" in the messages subdirectory to do this.
-
-    Next, create the subdirectory templates/xx and translate each of
-    the files in templates/en/*.{html,txt}.  These you should also
-    donate back to the Mailman project.
-
-    To make Mailman and your lists aware of the new language, follow
-    the directions in the section above.
-
-
-TRANSLATION HINTS
-
-    Q: If your language uses non-ASCII characters, such as the cedilla in
-       French, how should you add these to the catalogs and templates?
-
-    A: For any message that is destined for the web interface, use an
-       HTML entity reference where appropriate.  For messages destined
-       for email, you should use the non-ASCII characters explicitly.
-       This includes both for the message catalog and the templates.
-
-
-RESYNCHRONIZING THE CATALOG
-
-    As Mailman development continues, new updated catalogs
-    (i.e. mailman.pot files) will be made available.  As mailman.pot
-    changes, the individual language catalogs
-    (i.e. xx/LC_MESSAGES/mailman.po files) need to be updated as well.
-
-    In general, I as the Mailman maintainer will merge the new
-    catalogs with the individual language catalogs, and commit the
-    updates to CVS.  Translators should grab the new mailman.po files
-    from CVS and update the translated messages.  They should also
-    update the template translations.
-
-    For best results, you will probably want to keep current on
-    changes to Mailman 2.1 in the CVS.  As Mailman 2.1 moves towards
-    final release, the catalogs and templates should start to
-    stabilize.  Alternatively, occasionally I will make new English
-    language packs available on SourceForge, and you can use these to
-    create your translations.
-
-
-DONATING YOUR TRANSLATION BACK TO MAILMAN
-
-    We'd really appreciate it if you donate your translations back to
-    the Mailman project, so that others can benefit from your effort.
-    You'll get credit of course, in the Mailman documentation.  Here
-    are the steps to donate your translations, either the first time
-    or subsequent updates.
-
-    The best thing to do is to send me <barry@python.org> a "tarball",
-    i.e. a gzip'd tarfile, that can be unpacked in the top level
-    directory of the Mailman CVS tree.  This would be the directory
-    containing this README-I18N.en file.
-
-    Your tarball should contain two directories, where your donated
-    language is `xx':
-
-        templates/xx
-        messages/xx
-
-    In templates/xx there should be the translated templates, all the
-    .txt and .html files, for your language, mirroring those in the
-    English template directory (always the master copy).
-
-    In messages/xx you should have a single directory LC_MESSAGES, and
-    in that directory a file called mailman.po, which is the human
-    readable catalog for your language.  Do not send me the mailman.mo
-    file, since I'll recreate it on my end, and that'll save on the
-    size of the tarball.
-
-    That's basically it.  If you need to include a README, please call
-    it README.xx and put it in the messages/xx directory.  README.xx
-    can be in your native language.
-
-    You can email the tarball to me, and if this is the first
-    installation of the language, please tell me what the
-    add_language() call in Defaults.py.in should be for your
-    language.
-
-
-CURRENT LIST OF LANGUAGE SUPPORTED OUT-OF-THE BOX
-
-    See http://www.list.org/i18n.html
-
-
-MORE INSTRUCTIONS
-
-    Here is the recipe that Simone Piunno used for the Italian
-    translations:
-
-    "You can start without much technical knowledge, but if you want
-    to keep your translation up-to-date (while the development branch
-    evolves into the next stable release) you'd better learn how to
-    use cvs and diff.
-
-    Here is my recipe.
-
-    Basically, you'll start by copying templates/en/* to your sandbox dir
-    and then translating each file.  Keep in mind that %(foo)s is a
-    variable reference (much like %s in C) and must be left untouched.
-    Also, you must be able to recognize a markup tag (eg, <foo>) because
-    they must be left untouched too, and you should know how to escape
-    non-ASCII characters, e.g. "è" -> "&egrave;", but only in html files.
-    Remember that if you need a literal % sign, it must be doubled: %%
-
-    Next, you copy messages/mailman.pot, renaming it to serbian.po.
-    You can open this file with kbabel (a tool included in KDE SDK) and
-    translate each string (original on the higher half of the window, your
-    translation on the bottom half).
-
-    If you are a masochist, you can even use emacs PO mode ;)
-    Keep attention to the same markers and escaping as above, with the added
-    complexity that here it's harder to say when a string is html (e.g. used
-    for web UI) or pure text (e.g used for email interface)
-
-    Then you try to compile you .po file:
-
-        msgfmt -v -o serbian.mo serbian.po
-
-    No error messages should appear.
-
-    Next, copy your files on an installed mailman tree, and run
-    bin/transcheck XX, where XX is your country code.
-
-    No warning should appear (but maybe some warning is ok, if you really
-    know what you're doing).
-
-    Now, try to run your translation (add an "add_language" line to
-    Mailman/Defaults.py) and check the many scattered pieces blend
-    together well.  Sometimes you'll need some adjustment.
-
-    When you're satistied, pack up a tar.gz with the following structure:
-
-    messages/XX/LC_MESSAGES/mailman.po
-    templates/XX/admindbdetails.html
-    templates/XX/admindbpreamble.html
-    .
-    .
-    templates/XX/userpass.txt
-    templates/XX/verify.txt
-
-    (XX is your country code) and send it to Barry Warsaw.  Do not
-    include the mailman.mo file if you can help it.
-
-    By that time, your translation could be somewhat obsolete, because
-    templates and mailman.pot could have been evolved meanwhile.
-
-    Don't panic.
-
-    You'll need to check diffs to find what changed and how, so that
-    you can easily update your files.
-
-    Save everything everytime, you'll need it.
-
-
-
-Local Variables:
-mode: text
-indent-tabs-mode: nil
-End:
diff --git a/docs/readmes/README.CONTRIB b/docs/readmes/README.CONTRIB
deleted file mode 100644
index c8b479425..000000000
--- a/docs/readmes/README.CONTRIB
+++ /dev/null
@@ -1,17 +0,0 @@
-Mailman - The GNU Mailing List Management System
-Copyright (C) 2001-2007 by the Free Software Foundation, Inc.
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
-Encrypted mailing lists
-
-    Raphinou <rb@raphinou.com> has documented a setup for encrypted
-    mailing lists at
-
-        http://www.raphinou.com/smailman
-
-
-
-Local Variables:
-mode: indented-text
-indent-tabs-mode: nil
-End:
diff --git a/docs/readmes/README.NETSCAPE b/docs/readmes/README.NETSCAPE
deleted file mode 100644
index 424fa80d8..000000000
--- a/docs/readmes/README.NETSCAPE
+++ /dev/null
@@ -1,57 +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
-
-
-NETSCAPE ISSUES
-
-    Some of your users may experience problems sending mail to a
-    members-only list, if they are using Netscape Communicator as
-    their MUA.  Communicator 4.x on Linux has been observed to insert
-    bogus unqualified Sender: headers -- i.e. Sender: headers with
-    only the username part of the email address.  Other version of
-    Netscape may also have the same bug.
-
-    By default, members-only lists use the From: header as the first
-    field to authenticate against, falling back to Sender:.  The site
-    administrator can also configure Mailman to always use Sender:
-    first.  If Sender: is used, and it exists in the email message,
-    but it is unqualified, it will never match a mailing list member's
-    address, and their post will always be held for approval.
-
-    In the future, Mailman will improve its algorithm for finding a
-    matching address, but in the meantime, M. A. Lemburg <mal@lemburg.com> 
-    provides the following advice.  You can send this snippet to any user
-    whose posts are being held for seemingly no reason.
-
-        Edit the two .js files in your .netscape directory (liprefs.js and
-        preferences.js) to include the function call:
-
-        user_pref("mail.suppress_sender_header", true);
-
-        BTW, the binary includes a comment which says that this is only
-        necessary on Unix.
-
-        Since Communicator regenerates this file upon exit, the change
-        must be done when Communicator is not currently running.  With the
-        next start, it will stop adding the Sender: header and things
-        start to work like a charm again.
-
-    The reason things start to work again, is that Mailman falls back to
-    authenticating the From: header if the Sender: header is missing,
-    even if the site administrator has configured things to look at
-    Sender: first.
-
-
-MOZILLA
-
-    There are no known problems with Mozilla 0.9.x at this time.  I
-    don't know whether the above Netscape problem also affects
-    Mozilla.
-
-
-
-Local Variables:
-mode: indented-text
-indent-tabs-mode: nil
-End:
diff --git a/docs/readmes/README.USERAGENT b/docs/readmes/README.USERAGENT
deleted file mode 100644
index d8c657c5e..000000000
--- a/docs/readmes/README.USERAGENT
+++ /dev/null
@@ -1,49 +0,0 @@
-Mailman - The GNU Mailing List Management System
-Copyright (C) 2001-2007 by the Free Software Foundation, Inc.
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
-
-INTRODUCTION
-
-    Mailman is compliant with RFC 2369, which specifies a number of
-    List-* headers that mailing list management software should add to
-    every outbound email message.  These headers are designed to make
-    it easy for mail user agents (MUAs) to assist users in common
-    mailing list tasks, such as getting help or unsubscribing.
-
-    At this time, not all MUAs understand the RFC 2369 headers, and
-    instead of suppressing those List-* headers, they show them to the
-    user.  Many list managers report that this can generate a large
-    amount of support requests from their user base.
-
-    In Mailman 2.0, you cannot turn off the List-* headers without
-    hacking the Mailman source.  Because these headers are in the
-    long-term benefit of end-users, it is strongly encouraged to leave
-    these headers in and lobby the MUA vendors to support them.  In
-    the meantime, you can provide your users with the following
-    information to help them suppress these headers.
-
-
-EUDORA USERS
-
-    Mike Noyes provides the following suggestion:
-
-    You can hide the new list headers. Edit your Eudora.ini file, and
-    add this line under [settings].
-
-    TabooHeaders=List,X-UID,Received,Status,X-UIDL,Message,In-Reply, \
-    X-Priority,Mime-Version,Content,X-Persona,Resent-Message,References, \
-    Return,X400,X-400,Mail-System,Errors-To,X-List,Delivery,Disposition, \
-    X-Juno,Precedence,X-Attachments,X-MSMail,X-MimeOLE,X-Nav
-
-    note: everything other than "List" is the default
-
-    ref. Eudora .ini Settings TabooHeaders
-    http://www.eudora.com/techsupport/ini.html
-
-
-
-Local Variables:
-mode: text
-indent-tabs-mode: nil
-End:
diff --git a/docs/readmes/TODO.txt b/docs/readmes/TODO.txt
deleted file mode 100644
index c18bdfaec..000000000
--- a/docs/readmes/TODO.txt
+++ /dev/null
@@ -1,172 +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
-
-
-The Mailman Wishlist
-(Last Update: $Date: 2007-04-30 21:16:19 +0100 (Mon, 30 Apr 2007) $)
-
-    Here's the wish list for future versions of Mailman.  Many new
-    features have been added to Mailman 2.1, and it is currently
-    undecided whether the next release will be 2.2 or 3.0.
-
-    Please also see the official Mailman wiki at http://wiki.list.org
-
-Email Handling
-    - Re-implement the bulk mailer to do DNS lookups and remote MTA
-      delivery directly (optional).
-    - For low-traffic sites, a queued message could trigger a qrunner
-      process.  It would work until all mail was delivered, then sleep
-      and exit if no new work arrived.
-    - Strip any addresses of members who have nodupe turned on, from
-      the Cc headers of the list copy of a message.
-    - Separate processing for MIME and plaintext digests.  E.g. you
-      might want to filter images out of plaintext but not MIME
-      digests.
-
-Documentation
-    - A detailed feature list
-    - A user's guide
-    - A site-admin's guide
-    - A list-admin's guide
-    - More on-line documentation and UI help
-    - A developer's guide w/ architecture and API information
-    - manpages for the scripts in bin and cron
-    - Integrate Christopher Kolar's documentation
-
-General Web UI
-    - NO DEAD ENDS and every web page is reachable.
-    - All web UI must be configurable so that it more easily
-      integrates into an existing site's design.  Probably means using
-      a better template language/system like Zope's Presentation
-      Templates, Quixote, or PHP.
-    - Default UI should add a navigation sidebar to all web pages.
-    - Web pages should never mention disabled features.
-    - Allow a site admin and list admins to categorize lists, so that
-      they can be better organized on the listinfo and admin overview
-      pages.
-
-List Administration
-    - Allow the moderator to edit posts being held for approval (make
-      it evident, either through a header or other means that the
-      message was edited by the moderator).
-    - Allow the admin to disable option settings by users
-    - Allow admins to block nomail settings
-    - Allow admins to control and set individual headers, adding,
-      removing, or overriding those in the original message (sometimes
-      very useful, but could be dangerous!)
-    - New moderation choice: archive but don't send to list.
-    - New moderation choice: annotate and send to author for
-      resubmittal.  Or just be able to annotate the message for
-      multiple moderator scenarios.
-    - Better integration with moderated newsgroups (and allow some
-      addresses to bypass even that moderation and be delivered to a
-      secondary channel, like moderators@isc.org).
-    - Allow a list to be marked `disabled' so things like the replybot
-      still works, and the archives are still available, but mail
-      posted to the list is always returned unsent.
-    - Ability to `sideline' some messages in the moderation queue
-    - Hook moderation up to a whitelist a la TMDA.  A non-member
-      message gets held in a non-admindb queue, and the sender gets a
-      confirmation message.  When they confirm, we moderate the
-      message as normal, but if they don't we assume it's spam (after
-      some period of time) and discard it.  The admin should be able
-      to see all these super-quarantined messages with the flip of a
-      button.
-    - Add a moderation option to pass through any message which is a
-      reply to a message previously distributed through the list, even
-      if it comes from a non-member.  Treat that non-member as a
-      member for the duration of the thread.  Use In-Reply-To,
-      References and Message-ID to match these up.
-    - When a held message is forwarded (for admin editing and approved
-      resend) there should be a way to auto-discard the held message
-      when the approved resend is received.
-    - Have an option to sort the list of members by real name or email
-      address.
-    - Test a message for all hold criteria, record them all instead of
-      just the first match, and do a SpamAssassin like scoring to
-      decide whether the message should get held or not.
-
-List Membership
-    - Have one account per user per site, with multiple email
-      addresses and fallbacks.  Allow them to subscribe whichever
-      address they want to whichever list, with different options per
-      subscription.
-    - Allow the user to get BOTH normal and digested delivery (but I
-      still don't understand why someone would want this)
-    - More flexible digests: index digests (subject and authors only,
-      with URLs to retrieve the article)
-    - Timed vacations, allowing a user to postpone or discard email
-      for a certain number of days or weeks.
-    - Keep user-centric stats, such as the date the user was
-      subscribed, the date of their last change to their account, the
-      date they last sent a message through the list.  Perhaps also
-      log each message they send through the list.
-
-Site Administration
-    - Allow the site admin to define list styles or themes, and list
-      admins to choose one of the canned styles to apply to their
-      list.
-    - Allow the site admin to send an email message to all the list
-      admins using a mechanism similar to the Urgent: header (possibly
-      by addressing it to mailman@site.dom).
-
-Other Usability Improvments
-    - A better strategy is needed for sub-lists and super-lists,
-      including dealing with the resulting password reminders and
-      authorization to modify the sub & superlists.
-    - Add a limit on the number of posts from any one individual
-      within a period of time (1 post per day, 10 per week, etc).
-      Also, limits on mailbacks, infos, etc.
-
-Mailcmd interface
-    - Provide an email interface to all administrative commands
-    - Allow email unsubs from matching address to unsubscribe,
-      possibly adding an "allow open unsubscribes" option to control
-      this.  Also, adding a confirmation with click-thru confirmation
-      to resubscribe.
-    - For email subscribes, keep an audit of where requests are coming
-      from, and send the original request headers in the confirmation
-      message.  Helps track down subscribe bombs.
-    - Investigate Majordomo2's email admin capabilities.
-    - Support the `which' command.
-
-Portability & architecture
-    - Use a real transactional database for all information, and allow
-      various bits of information to come from different sources (a
-      relational database, ZODB, LDAP, etc)
-    - Member profiles
-    - Allow lists of the same name in two different virtual domains
-    - Should be able to gather statistics, such as deliveries/day,
-      performance, number of subscribers over time, etc.
-    - Implement something like Roundup's nosy lists, maybe even
-      integrate with Roundup.
-    - Split Mailman into libraries so, e.g. the delivery part could be
-      used by other projects.
-
-Bounce handling
-    - Add more patterns for bounce handling (never ending)
-    - Send mail to people who are being removed without their knowledge
-      (even though they're likely not to get it).
-
-Pipermail + Archiving mechanism
-    - Search engine for archives
-    - Provide downloadable tar.gz's of the html archives
-    - sort by date should go most-recent to oldest
-    - allow list owner to edit archive messages
-    - optional form front-end to public interfaces as a filter to
-      address harvesters.
-    - In general the whole Pipermail subsystem needs a good rewrite.
-    - Write an API between Mailman and the archiver so that message
-      footers can contain the URL to the archived message.
-
-Code cleanup
-    - Turn all remaining string exceptions into class exceptions
-    - Unit and system test suite! (ongoing)
-
-
-
-Local Variables:
-mode: indented-text
-indent-tabs-mode: nil
-End:
diff --git a/docs/readmes/UPGRADING.txt b/docs/readmes/UPGRADING.txt
deleted file mode 100644
index f19d10a11..000000000
--- a/docs/readmes/UPGRADING.txt
+++ /dev/null
@@ -1,392 +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
-
-
-UPGRADING FROM PREVIOUS VERSIONS
-
-    For the most part, upgrading Mailman entails installing the latest version
-    over the existing version.  Usually, you can unpack the new release, run
-    'configure' with the same options you used in your previous install, and
-    then do a 'make install'.  However, there are some changes that may need
-    to be taken care of manually.
-
-    What you need to do depends on the version you are using and the version
-    you are upgrading to.  In all cases, you should first turn off your mail
-    and web access to your Mailman installation.  You're essentially upgrading
-    a database, and it's usually a good idea to make sure the database cannot
-    be modified in the middle of the upgrade.
-
-    My recommendations are:
-
-    - Turn off your incoming mail daemon.  Most remote smtp servers will
-      simply queue up messages destined for your domain if port 25 is shut
-      off.
-
-    - Temporarily disable web access to Mailman.  You can do this by either
-      turning off your web server temporarily, or by setting up a temporary
-      redirect to a "service unavailable" page for the Mailman URLs.  Refer to
-      your web server documentation for details.
-
-
-UPGRADING FROM 2.1.4 to 2.1.5
-
-    In Mailman 2.1.5, some significant changes have been made to the file
-    formats for qfiles and the pendings database.  All care has been taken to
-    make sure the upgrades happen automatically and smoothly, but you should
-    double check and, for the ultra-paranoid, make backups of your Mailman
-    site before you upgrade.  BE SURE TO TURN OFF MAILMAN AS DESCRIBED ABOVE
-    BEFORE YOU UPGRADE.
-
-    Specifically, in MM2.1.4 every message in the queues were represented by
-    two files, a .msg or .pck file containing the email message, and a .db
-    file containing metadata about the message.  In MM2.1.5 this has been made
-    more efficient by using only one file (with a .pck extension) for both the
-    message and metadata.  This should make MM2.1.5 half as hostile to the
-    file system.
-
-    The bin/upgrade script, which is run automatically when you upgrade,
-    should convert all the old style qfiles to the new style qfiles.  Note
-    that this could take a long time if you have a lot of files in your qfiles
-    subdirectories.  Pay particular attention to files you might have in
-    qfiles/shunt; these will get upgraded too, although files in qfiles/bad
-    will not.
-
-    In MM2.1.4, the database file containing pending actions (i.e
-    subscriptions, unsubscriptions, message holds, etc.) was shared globally
-    among all mailing lists.  In MM2.1.5, each list now has its own pending
-    database file.  All care has been taken to properly split pending actions
-    from the global to the list-specific files, but it's possible there are
-    bugs here.  Best practice is to clear all pending actions before you
-    upgrade, although this is not always possible.
-
-
-UPGRADING FROM 2.0.x to 2.1
-
-    When you upgrade from Mailman 2.0.x to Mailman 2.1, you should double
-    check that your moderation and privacy options are still set the way you
-    want them.  The Mailman options dealing with moderation and privacy have
-    changed significantly, to make them easier to understand and control.
-    Ever effort was taken to translate the old configuration variables to the
-    new configuration variables, but because the old semantics were so
-    complex, it is possible your settings may not have been correctly
-    translated.
-
-    Check especially the values for (in Privacy -> Sender Filters)
-    default_member_moderation, generic_nonmember_action, and
-    accept_these_nonmembers.  Check also the moderation flag on member
-    accounts in the Membership Management screen.
-
-    In Mailman 2.1, the qrunner subsystem has been completely
-    rewritten.  You no longer start qrunner from cron!  Instead, there
-    is a bin/mailmanctl script which is used to start, stop, and
-    restart mail delivery.  This script is appropriate to use as a
-    Unix init script.  Be sure to update your crontab with the new
-    cron/crontab.in file.
-
-    NOTE: It is very important that if you are upgrading from a
-    pre-MM2.1alpha2 system to a post-MM2.1alpha2 system that you let
-    the old qrunner process clear any and all messages sitting in the
-    qfiles/ directory *BEFORE* you upgrade.  Otherwise after the
-    upgrade, those messages will not get delivered, and I'm not
-    exactly sure yet how to upgrade those pending messages.
-
-    NOTE: When upgrading to Mailman 2.1, you will need to regenerate
-    your aliases files.  There have been many changes to the alias
-    names, the programs they map to, and the name of the wrapper
-    script.  See README.<yourMTA> for details of making Mailman work
-    with your mail server.
-
-    To regenerate your aliases, use the bin/genaliases script.
-
-    Mailman 2.1 introduces multilingual (a.k.a. internationalization
-    or i18n) support.  Previously only one language per list was
-    supported, and it was assumed that this language would be English.
-    The upgrade script for Mailman 2.1 creates a subdirectory `en'
-    inside each lists/<listname> directory.  It then copies all the
-    .txt and .html files from lists/<listname> into
-    lists/<listname>/en.
-
-    If you have modified those templates to contain non-English text,
-    you will have to manually rename the en subdirectories to the
-    language code for the language of your templates.  Mailman's
-    upgrade script should handle cleaning up any templates which are
-    duplicates of the defaults, but you'll want to double check this
-    manually.
-
-    If you are running a MM2.0.x system with non-standard patches
-    applied, you might have some other problems with your upgrade.
-    Here are some instances we know about:
-
-    - If you've applied patch #413752 (coerce to plaintext), then your
-      upgraded will not go smoothly.  Take a look at patch #651406 for
-      an unofficial solution.
-
-      http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=413752
-      http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=651406
-
-
-UPGRADING INDIVIDUAL LISTS
-
-    If you're nervous about upgrading all of your lists to 2.1 in one
-    go, you can move them and upgrade them one at a time.  Start by
-    doing a clean Mailman 2.1 installation in an empty directory --
-    call it $MM21.  (I'll assume your Mailman 2.0 installation is in
-    $MM20.)
-
-    Doing this means you'll have co-habiting Mailman 2.0 and 2.1
-    installations for a while, until you have moved all of your lists
-    to Mailman 2.1.  Depending on your MTA and web server, this could
-    be transparent and painless, or it could be an ongoing headache.
-
-    If you use Apache with mod_rewrite, then it's fairly
-    straightforward to set things up so that both Mailman 2.0 and 2.1
-    inhabit the /mailman and /pipermail URL-space of your server; this
-    makes the transition almost transparent to list admins and
-    subscribers.  See below for details.
-
-    Now, for each list that you want to move, you'll have to
-
-      * Shut down your MTA.
-
-        If you have a lot of outgoing list traffic, you might need to
-        leave your MTA up but only let it accept connections from
-        127.0.0.1 (localhost), so Mailman 2.0 can flush its queue.
-        How to do this is MTA-dependent; for Exim, you can set
-        "local_interfaces = 127.0.0.1" and "kill -HUP" the Exim
-        daemon.
-
-      * Shut down your web server.  For a more professional look, or
-        if you want to allow people to keep accessing the rest of your
-        web site, you could make your web server respond to all
-        /mailman/ URLs with a "temporarily unavailable" message.
-
-        How to do this is web server-dependent; with Apache and
-        mod_rewrite, this does the trick:
-
-          RewriteRule ^/mailman/.* /var/www/unavailable.html [L]
-
-        (Of course, you'll have to supply your own
-        /var/www/unavailable.html.)
-
-      * Force Mailman 2.0 to process its queue:
-
-          python -S $MM20/cron/qrunner
-
-        (This is only necessary if there are any files in $MM20/qfiles;
-        if you need to do this, make sure you left your MTA listening to
-        127.0.0.1.)
-
-      * Move the list:
-
-          cd $MM20
-          mv -i lists/foo-list $MM21/lists
-          mv -i archives/private/foo-list $MM21/archives/private
-          mv -i archives/private/foo-list.mbox $MM21/archives/private
-          rm archives/public/foo-list
-          rm archives/public/foo-list.mbox
-          cd $MM21
-          bin/withlist -l -r fix_url mylist
-
-        (The fix_url step will not be necessary if your Mailman 2.0
-        and 2.1 installations will be sharing the same URL-space.)
-
-      * Edit your web server config so the list's URLs continue to
-        work.  There are two possible approaches here; the simpler way
-        is to setup a new slice of URL-space that will be used by your
-        Mailman 2.1 installation, eg. /mailman-21:
-        With Apache and mod_rewrite:
-
-          RewriteRule /mailman/(.*)/(foo-list.*) /mailman-21/$1/$2 [R=temp]
-
-        (The [R=temp] assumes that "/mailman-21/" is a temporary URL,
-        and you'll move all your lists to "/mailman/" when the
-        transition to Mailman 2.1 is complete.)
-
-        If you don't want to expose ugly temporary URLs like
-        "/mailman-21" to the world, it's only slightly more work to make
-        Mailman 2.0 and 2.1 share the same slices of URL-space.  Here's
-        how to do it with Apache and mod_rewrite:
-
-          RewriteRule ^/mailman/(.*)/(foo-list.*) \
-                      $MM21/cgi-bin/$1/$2 \
-                      [T=application/x-httpd-cgi]
-
-        Not only is this more aesthetically pleasing, it's faster -- no
-        redirects.
-
-        In either case, you'll want to rewrite the list's archive URLs
-        to Mailman 2.1's archive:
-
-          RewriteRule ^/pipermail/(foo-list.*) $MM21/archives/public/$1
-
-      * Restart your web server (or disable the "temporarily
-        unavailable" stuff).
-
-      * Restart your MTA (or make it listen to more than just
-        127.0.0.1).
-
-
-UPGRADING FROM 2.0 to 2.0.x (where x >= 1)
-
-    Nothing much more than running "make install" (after upgrading)
-    should be necessary.
-
-
-UPGRADING FROM 2.0 beta to 2.0 final
-
-    You MUST re-run configure; running config.status is not sufficient
-    due to some recent changes in the autoconf scripts.  You can do a
-    head of config.status if you don't remember the options you
-    originally ran configure with.
-
-    The cron jobs for Mailman 2.0 final have changed considerably,
-    including the frequency with which they run.  You should reload
-    misc/crontab.in for the `mailman' user to get the right settings.
-    See the INSTALL file for details.
-
-    FAILURE TO DO THIS WILL RESULT IN A LESS THAN OPTIMALLY FUNCTIONAL
-    MAILMAN INSTALLATION.
-
-
-UPGRADING FROM 1.x to 2.x
-
-    In addition to the instructions above, I highly recommend that you
-    make sure your Mailman queue is cleared /before/ upgrading.
-
-    Mailman version 1.x had a cron script called run_queue which was
-    part of its bulk mailer.  With Mailman 2.x there is no default
-    bulk mailer (it lets the MTA handle this), and it is currently
-    unknown what the effects of upgrading are on the run_queue script,
-    but I'll bet it's not good. :)
-
-    The way to make sure that your Mailman queue is empty is to look
-    in your $prefix/data directory.  If you see any files that start
-    with "mm_q." you've still got messages waiting on the queue.  You
-    can run $prefix/cron/run_queue by hand until the queue is cleared.
-    Multiple invocations of this script won't help though; they lock
-    each other out.  Also, be warned that clearing the queue can take
-    a while and may cause a large load on your system (two reasons why
-    all this stuff has been redesigned in 2.x :).
-
-    You do not need to run "make update" if you are upgrading from
-    version 1.0 or 1.1 to version 2.0, since this is now run
-    automatically when you do a "make install".  However you should
-    modify your crontab entries to execute cron/qrunner instead of
-    cron/run_queue.  You can also safely remove the file
-    $prefix/cron/run_queue.
-
-    If you are upgrading from a pre-1.0 beta, you need to follow the
-    instructions below.
-
-
-UPGRADING FROM PRE-1.0 to 2.x
-
-    You need to do a few extra things to make sure that the file
-    system layout for the early 1.0 betas is upgraded to the 1.x
-    configuration.  There are two ways to do this.
-
-    First, from the source directory, after you've done a "make
-    install" you can run "make update".  "make update" creates a file
-    named "update.log" in the top level of the source distribution.
-    If the script that updates the Mailman filesystem encounters
-    something that is not resolvable, it will log info about this to
-    "update.log".  This is worth checking after the upgrade completes.
-
-    You can also just change to the installation directory (i.e. $prefix)
-    and run bin/update.  This is the same as above except that the
-    update.log file is not generated.
-
-    Check your crontab entry.  Remove any runs of obsolete scripts, in
-    particular cron/upvolumes_yearly, cron/upvolumes_monthly, or
-    cron/archive.
-
-
-WHAT "MAKE UPDATE" DOES
-
-    Below is an annotated listing of the things that "make update"
-    does.  Hopefully, this will help resolve any problems you are
-    having.
-
-    Note that it can't hurt to run "make update" each time you
-    upgrade, but if you're running version 1.0 or newer, it won't help
-    much either!
-
-    - To upgrade to 1.0b10, you will need to copy
-      templates/options.html to lists/<listname>/options.html for each
-      mailing list you have.  However, if you have edited the
-      options.html file, say from the Web interface, you will have to
-      merge these changes in manually.
-
-    - The upgrade to 1.0b7 included the removal of
-      Mailman/smtplib.py{,c} since Mailman now uses the default Python
-      1.5.2 version of smtplib.
-
-    - Archiving files are moved around as part of integrating
-      Pipermail into Mailman, as of 1.0b6.  In particular,
-
-      1) if a list has only a private mbox archive
-      $prefix/archives/private/<listname> is moved to
-      $prefix/archives/private/<listname>.mbox/<listname>
-
-      2) if a list has only a public mbox archive
-      $prefix/archives/public/<listname> is moved to
-      $prefix/archives/private/<listname>.mbox/<listname>
-
-      and a symlink is made that points
-      $prefix/archives/public/<listname>.mbox to
-      $prefix/archives/private/<listname>.mbox/<listname>
-
-      3) if a list has both private and public mbox archives,
-      make update picks one of the above 2 configurations based on
-      whether or not the list currently is archived publicly.  It then
-      renames the other mbox to mbox.preb6.
-
-      4) if a list used recent CVS sources, where archives were placed in
-      $prefix/public_html/archives, then these are moved to
-      $prefix/archives/private/<listname> and a symlink is made from
-      $prefix/archives/public/<listname> to that spot if the list's
-      archives are public.  Also, a permissions-related security
-      problem is removed.
-
-      To integrate mbox archives of old lists, log in as user `mailman'
-      and run $prefix/bin/arch <listname> <path-to-mbox-archive>.
-
-      Also, by default, beta6 does both mbox and html based archiving,
-      but you can configure Mailman to do one, both, or neither.
-      Please see $prefix/Mailman/Defaults.py for details.
-
-      There was a short period of time when the CVS sources archiving
-      code was not organized into its own package.  The pickled
-      articles in the archives that were placed into archives during
-      this period stored the path to the module HyperArch, but that
-      module has moved.  You can quick fix this by running
-
-      ln -s $prefix/Mailman/Archiver/HyperArch.py \
-              $prefix/Mailman/HyperArch.py
-
-    - If upgrading from version 1.0b4 or earlier, "make update" moves
-      list-specific templates.  For each list,
-      $prefix/templates/<listname>/* is moved to $prefix/lists/<listname>.
-      Please reference the generic templates in $prefix/templates to see
-      if any variables have changed (There shouldn't be many, only
-      options.html was updated from b5 to b6).
-
-      For really old versions of Mailman, you may not even have
-      <listname> subdirectories in $prefix/templates!  In this case
-      you will need to manually copy some files into your new list
-      directories.  Here's an example shell command that will do the
-      trick:
-
-      cp templates/{archives,handle_opts,listinfo,roster,subscribe}.html lists/<listname>
-
-    - Some modules that existed in previous versions, but that have
-      been replaced with newer (differently named) modules, are
-      removed.
-
-
-
-Local Variables:
-mode: indented-text
-indent-tabs-mode: nil
-End: