7 files changed, 927 insertions, 0 deletions

diff --git a/docs/readmes/INSTALL.txt b/docs/readmes/INSTALL.txt
new file mode 100644
index 000000000..9485a392e
--- /dev/null
+++ b/docs/readmes/INSTALL.txt
@@ -0,0 +1,25 @@
+Mailman - The GNU Mailing List Management System
+Copyright (C) 1998-2005 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
new file mode 100644
index 000000000..ade319bd8
--- /dev/null
+++ b/docs/readmes/README-I18N.en
@@ -0,0 +1,213 @@
+Mailman - The GNU Mailing List Management System
+Copyright (C) 2001-2003 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
new file mode 100644
index 000000000..c378f3bce
--- /dev/null
+++ b/docs/readmes/README.CONTRIB
@@ -0,0 +1,17 @@
+Mailman - The GNU Mailing List Management System
+Copyright (C) 2001,2002 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
new file mode 100644
index 000000000..9828127fc
--- /dev/null
+++ b/docs/readmes/README.NETSCAPE
@@ -0,0 +1,57 @@
+Mailman - The GNU Mailing List Management System
+Copyright (C) 1998,1999,2000,2001,2002 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
new file mode 100644
index 000000000..af5718ecb
--- /dev/null
+++ b/docs/readmes/README.USERAGENT
@@ -0,0 +1,49 @@
+Mailman - The GNU Mailing List Management System
+Copyright (C) 2001,2002 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
new file mode 100644
index 000000000..8debf4264
--- /dev/null
+++ b/docs/readmes/TODO.txt
@@ -0,0 +1,174 @@
+Mailman - The GNU Mailing List Management System
+Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
+51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
+
+
+The Mailman Wishlist
+(Last Update: $Date: 2007-01-14 04:34:29 +0000 (Sun, 14 Jan 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 Mailman design notes wiki at
+
+    http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage
+
+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
new file mode 100644
index 000000000..6f8ede6e1
--- /dev/null
+++ b/docs/readmes/UPGRADING.txt
@@ -0,0 +1,392 @@
+Mailman - The GNU Mailing List Management System
+Copyright (C) 1998-2004 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: