Updated documentation for 2.1.10 final.

1 files changed, 336 insertions, 324 deletions

diff --git a/doc/mailman-admin.txt b/doc/mailman-admin.txt
index 210fbec8..8f8a74c2 100644
--- a/doc/mailman-admin.txt
+++ b/doc/mailman-admin.txt
@@ -1,18 +1,19 @@
+
    #GNU mailman - list Administration Manual Contents About this
    document... About this document...
 
    Previous Page Up one Level Next Page GNU Mailman - List Administration
-                                                     Manual
-     __________________________________________________________________
+                                   Manual
+     _________________________________________________________________
 
 GNU Mailman - List Administration Manual
 
    Barry A. Warsaw
 
    Release 2.1
-   December 5, 2007
+   April 21, 2008
 
-                                  Front Matter
+                                 Front Matter
 
   Abstract:
 
@@ -61,9 +62,9 @@ Contents
    discussion lists and announce-only lists. Mailman has extensive
    features for controlling the privacy of your lists, distributing your
    list as personalized postings or digests, gatewaying postings to and
-   from Usenet, and providing automatic bounce detection. Mailman provides
-   a built-in archiver, multiple natural languages, as well as advanced
-   content and topic filtering.
+   from Usenet, and providing automatic bounce detection. Mailman
+   provides a built-in archiver, multiple natural languages, as well as
+   advanced content and topic filtering.
 
    Mailman provides several interfaces to its functionality. Most list
    administrators will primarily use the web interface to customize their
@@ -90,8 +91,8 @@ Contents
      * mylist-leave@example.com - by sending a message to this address, a
        member can request unsubscription from the list. As with the -join
        address, the Subject: header and body of the message is ignored.
-       Note that mylist-unsubscribe@example.com is an alias for the -leave
-       address.
+       Note that mylist-unsubscribe@example.com is an alias for the
+       -leave address.
      * mylist-owner@example.com - This address reaches the list owner and
        list moderators directly.
      * mylist-request@example.com - This address reaches a mail robot
@@ -101,9 +102,10 @@ Contents
        members who's addresses have become either temporarily or
        permanently inactive. The -bounces address is also a mail robot
        that processes bounces and automatically disables or removes
-       members as configured in the bounce processing settings. Any bounce
-       messages that are either unrecognized, or do not seem to contain
-       member addresses, are forwarded to the list administrators.
+       members as configured in the bounce processing settings. Any
+       bounce messages that are either unrecognized, or do not seem to
+       contain member addresses, are forwarded to the list
+       administrators.
      * mylist-confirm@example.com - This address is another email robot,
        which processes confirmation messages for subscription and
        unsubscription requests.
@@ -118,13 +120,13 @@ Contents
    list owner and a list moderator. A list owner is allowed to change
    various settings of the list, such as the privacy and archiving
    policies, the content filtering settings, etc. The list owner is also
-   allowed to subscribe or invite members, unsubscribe members, and change
-   any member's subscription options.
+   allowed to subscribe or invite members, unsubscribe members, and
+   change any member's subscription options.
 
    The list moderator on the other hand, is only allowed to approve or
    reject postings and subscription requests. The list moderator can also
-   do things like clear a member's moderation flag, or add an address to a
-   list of approved non-member posters.
+   do things like clear a member's moderation flag, or add an address to
+   a list of approved non-member posters.
 
    Normally, the list owner and list moderator are the same person. In
    fact, the list owner can always do all the tasks a list moderator can
@@ -145,8 +147,8 @@ Contents
    Every mailing list is also accessible by a number of web pages. Note
    that the exact urls is configurable by the site administrator, so they
    may be different than what's described below. We'll describe the most
-   common default configuration, but check with your site administrator or
-   hosting service for details.
+   common default configuration, but check with your site administrator
+   or hosting service for details.
 
    Mailman provides a set of web pages that list members use to get
    information about the list, or manage their membership options. There
@@ -171,8 +173,8 @@ Contents
    http://lists.example.com/mailman/admindb/mylist (note the admindb url
    as opposed to the admin url). Again, the first time you visit this
    page, you'll be presented with a login page, on which you can enter
-   either the list moderator password or the list owner password. Again, a
-   session cookie is dropped in your browser. Note also that if you've
+   either the list moderator password or the list owner password. Again,
+   a session cookie is dropped in your browser. Note also that if you've
    previously logged in as the list owner, you do not need to re-login to
    access the administrative requests page.
 
@@ -180,8 +182,8 @@ Contents
 
    This section will outline the basic architecture of GNU Mailman, such
    as how messages are processed by the sytem. Without going into lots of
-   detail, this information will help you understand how the configuration
-   options control Mailman's functionality.
+   detail, this information will help you understand how the
+   configuration options control Mailman's functionality.
 
    When mail enters the system from your mail server, it is dropped into
    one of several Mailman queues depending on the address the message was
@@ -196,52 +198,52 @@ Contents
    There are separate queues for the built-in archiver, the bounce
    processor, the email command processor, as well as the outgoing email
    and news queues. There's also a queue for messages generated by the
-   Mailman system. Each of these queues typically has one queue runner (or
-   ``qrunner'') that processes messages in the queue. The qrunners are
-   idle when there are no messages to process.
+   Mailman system. Each of these queues typically has one queue runner
+   (or ``qrunner'') that processes messages in the queue. The qrunners
+   are idle when there are no messages to process.
 
    Every message in the queues are represented by two files, a message
-   file and a metadata file. Both of these files share the same base name,
-   which is a combination of a unique hash and the Unix time that the
-   message was received. The metadata file has a suffix of .db and the
-   message file has a suffix of either .msg if stored in plain text, or
-   .pck if stored in a more efficient internal representation^1.
+   file and a metadata file. Both of these files share the same base
+   name, which is a combination of a unique hash and the Unix time that
+   the message was received. The metadata file has a suffix of .db and
+   the message file has a suffix of either .msg if stored in plain text,
+   or .pck if stored in a more efficient internal representation^1.
 
    As a message moves through the incoming queue, it performs various
-   checks on the message, such as whether it matches one of the moderation
-   criteria, or contains disallowed MIME types. Once a message is approved
-   for sending to the list membership, the message is prepared for sending
-   by deleting, adding, or changing message headers, adding footers, etc.
-   Messages in the incoming queue may also be stored for appending to
-   digests.
+   checks on the message, such as whether it matches one of the
+   moderation criteria, or contains disallowed MIME types. Once a message
+   is approved for sending to the list membership, the message is
+   prepared for sending by deleting, adding, or changing message headers,
+   adding footers, etc. Messages in the incoming queue may also be stored
+   for appending to digests.
 
-                         2 The List Configuration Pages
+                        2 The List Configuration Pages
 
    After logging into the list configuration pages, you'll see the
    configuration options for the list, grouped in categories. All the
    administrative pages have some common elements. In the upper section,
    you'll see two columns labeled ``Configuration Categories''. Some
-   categories have sub-categories which are only visible when you click on
-   the category link. The first page you see after logging in will be the
-   ``General Options'' category. The specific option settings for each
-   category are described below.
+   categories have sub-categories which are only visible when you click
+   on the category link. The first page you see after logging in will be
+   the ``General Options'' category. The specific option settings for
+   each category are described below.
 
    On the right side of the top section, you'll see a column labeled
-   ``Other Administrative Activities''. Here you'll find some other things
-   you can do to your list, as well as convenient links to the list
-   information page and the list archives. Note the big ``Logout'' link;
-   use this if you're finished configuring your list and don't want to
-   leave the session cookie active in your browser.
+   ``Other Administrative Activities''. Here you'll find some other
+   things you can do to your list, as well as convenient links to the
+   list information page and the list archives. Note the big ``Logout''
+   link; use this if you're finished configuring your list and don't want
+   to leave the session cookie active in your browser.
 
    Below this common header, you'll find a list of this category's
-   configuration variables, arranged in two columns. In the left column is
-   a brief description of the option, which also contains a ``details''
-   link. For many of the variables, more details are available describing
-   the semantics of the various available settings, or information on the
-   interaction between this setting and other list options. Clicking on
-   the details link brings up a page which contains only the information
-   for that option, as well as a button for submitting your setting, and a
-   link back to the category page.
+   configuration variables, arranged in two columns. In the left column
+   is a brief description of the option, which also contains a
+   ``details'' link. For many of the variables, more details are
+   available describing the semantics of the various available settings,
+   or information on the interaction between this setting and other list
+   options. Clicking on the details link brings up a page which contains
+   only the information for that option, as well as a button for
+   submitting your setting, and a link back to the category page.
 
    On the right side of the two-column section, you'll see the variable's
    current value. Some variables may present a limited set of values, via
@@ -250,12 +252,12 @@ Contents
    for the operation of the list, but others perform immediate actions
    (these are clearly labeled).
 
-   At the bottom of the page, you'll find a ``Submit'' button and a footer
-   with some more useful links and a few logos. Hitting the submit button
-   commits your list settings, after they've been validated. Any invalid
-   values will be ignored and an error message will be displayed at the
-   top of the resulting page. The results page will always be the category
-   page that you submitted.
+   At the bottom of the page, you'll find a ``Submit'' button and a
+   footer with some more useful links and a few logos. Hitting the submit
+   button commits your list settings, after they've been validated. Any
+   invalid values will be ignored and an error message will be displayed
+   at the top of the resulting page. The results page will always be the
+   category page that you submitted.
 
 2.1 The General Options Category
 
@@ -283,16 +285,16 @@ Contents
    owner
           This variable contains a list of email addresses, one address
           per line, of the list owners. These addresses are used whenever
-          the list owners need to be contacted, either by the system or by
-          end users. Often, these addresses are used in combination with
-          the moderator addresses (see below).
+          the list owners need to be contacted, either by the system or
+          by end users. Often, these addresses are used in combination
+          with the moderator addresses (see below).
 
    moderator
           This variable contains a list of email addresses, one address
-          per line, of the list moderators. These addresses are often used
-          in combination with the owner addresses. For example, when you
-          email mylist-owner@example.com, both the owner and moderator
-          addresses will receive a copy of the message.
+          per line, of the list moderators. These addresses are often
+          used in combination with the owner addresses. For example, when
+          you email mylist-owner@example.com, both the owner and
+          moderator addresses will receive a copy of the message.
 
    description
           In the general list overview page, which shows you every
@@ -303,12 +305,12 @@ Contents
           should be relatively short and no longer than one line.
 
    info
-          This variable contains a longer description of the mailing list.
-          It is included at the top of the list's information page, and it
-          can contain HTML. However, blank lines will be automatically
-          converted into paragraph breaks. Preview your HTML though,
-          because unclosed or invalid HTML can prevent display of parts of
-          the list information page.
+          This variable contains a longer description of the mailing
+          list. It is included at the top of the list's information page,
+          and it can contain HTML. However, blank lines will be
+          automatically converted into paragraph breaks. Preview your
+          HTML though, because unclosed or invalid HTML can prevent
+          display of parts of the list information page.
 
    subject_prefix
           This is a string that will be prepended to the Subject: header
@@ -337,14 +339,14 @@ Contents
 
           Note that this option is simply an aid for anonymization, it
           doesn't guarantee it. For example, a poster's identity could be
-          evident in their signature, or in other mail headers, or even in
-          the style of the content of the message. There's little Mailman
-          can do about this kind of identity leakage.
+          evident in their signature, or in other mail headers, or even
+          in the style of the content of the message. There's little
+          Mailman can do about this kind of identity leakage.
 
   2.1.2 Reply-To header munging
 
-   This section controls what happens to the Reply-To: headers of messages
-   posted through your list.
+   This section controls what happens to the Reply-To: headers of
+   messages posted through your list.
 
    Beware! Reply-To: munging is considered a religious issue and the
    policies you set here can ignite some of the most heated off-topic
@@ -366,8 +368,8 @@ Contents
      * Reply-To Munging Considered Useful
 
    The three options in this section work together to provide enough
-   flexibility to do whatever Reply-To: munging you might (misguidingly :)
-   feel you need to do.
+   flexibility to do whatever Reply-To: munging you might (misguidingly
+   :) feel you need to do.
 
    first_strip_reply_to
           This variable controls whether any Reply-To: header already
@@ -395,9 +397,9 @@ Contents
           When you set this variable to This list, a Reply-To: header
           pointing back to your list's posting address will be added.
 
-          When you set this variable to Explicit address, the value of the
-          variable reply_to_address (see below) will be added. Note that
-          this is one situation where Reply-To: munging may have a
+          When you set this variable to Explicit address, the value of
+          the variable reply_to_address (see below) will be added. Note
+          that this is one situation where Reply-To: munging may have a
           legitimate purpose. Say you have two lists at your site, an
           announce list and a discussion list. The announce list might
           allow postings only from a small number of approved users; the
@@ -413,8 +415,8 @@ Contents
 
   2.1.3 Umbrella list settings
 
-   TBD. Note that umbrella lists are deprecated and will be replace with a
-   better mechanism for Mailman 3.0.
+   TBD. Note that umbrella lists are deprecated and will be replace with
+   a better mechanism for Mailman 3.0.
 
   2.1.4 Notifications
 
@@ -431,29 +433,29 @@ Contents
           domain, including the lists where their subscription may be
           disabled. Second, it reminds people about their passwords for
           these lists, as well as the url for their personal options
-          pages, so that they can more easily configure their subscription
-          options.
+          pages, so that they can more easily configure their
+          subscription options.
 
           Some people get annoyed with these monthly reminders, and they
           can disable the reminders via their subscription options page.
-          For some lists, the monthly reminders aren't appropriate for any
-          of the members, so you can disable them list-wide by setting the
-          send_reminders variable to No.
+          For some lists, the monthly reminders aren't appropriate for
+          any of the members, so you can disable them list-wide by
+          setting the send_reminders variable to No.
 
    welcome_msg
-          When new members are subscribed to the list, either by their own
-          action, or the action of a list administrator, a welcome message
-          can be sent to them. The welcome message contains some common
-          boilerplate information, such as the name of the list,
+          When new members are subscribed to the list, either by their
+          own action, or the action of a list administrator, a welcome
+          message can be sent to them. The welcome message contains some
+          common boilerplate information, such as the name of the list,
           instructions for posting to the list, and the member's
-          subscription password. You can add additional information to the
-          welcome message by typing the text into the welcome_msg text
-          box. Note that because this text is sent as part of an email, it
-          should not contain HTML.
+          subscription password. You can add additional information to
+          the welcome message by typing the text into the welcome_msg
+          text box. Note that because this text is sent as part of an
+          email, it should not contain HTML.
 
    send_welcome_msg
-          This flag controls whether or not the welcome message is sent to
-          new subscribers.
+          This flag controls whether or not the welcome message is sent
+          to new subscribers.
 
    goodbye_msg
           Like the welcome_msg, a ``goodbye'' message can be sent to
@@ -463,8 +465,8 @@ Contents
           receive into the goodbye_msg text box.
 
    send_goodbye_msg
-          This flag controls whether or not the goodbye message is sent to
-          unsubscribing members.
+          This flag controls whether or not the goodbye message is sent
+          to unsubscribing members.
 
    admin_immed_notify
           List moderators get notifications of pending administrative
@@ -483,7 +485,8 @@ Contents
 
    respond_to_post_requests
           This variable controls whether the original sender of a posting
-          gets a notice when their message is held for moderator approval.
+          gets a notice when their message is held for moderator
+          approval.
 
   2.1.5 Additional settings
 
@@ -497,82 +500,84 @@ Contents
           period.
 
    new_member_options
-          Each member has a set of subscription options which they can use
-          to control how they receive messages and otherwise interact with
-          the list. While the members can change these settings by logging
-          into their personal options page, you might want to set the
-          default for a number of the member options. You can do that with
-          this variable, but see also the other categories for other
+          Each member has a set of subscription options which they can
+          use to control how they receive messages and otherwise interact
+          with the list. While the members can change these settings by
+          logging into their personal options page, you might want to set
+          the default for a number of the member options. You can do that
+          with this variable, but see also the other categories for other
           member defaults you can set.
 
           This variable presents a set of checkboxes which control the
           defaults for some of the member options. Conceal the member's
-          address specifies whether or not the address is displayed in the
-          list roster. Acknowledge the member's posting controls whether
-          or not Mailman sends an acknowledgement to a member when they
-          post a message to the list. Do not send a copy of a member's own
-          post specifies whether a member posting to the list will get a
-          copy of their own posting. Filter out duplicate messages to list
-          members (if possible) specifies whether members who are
-          explicitly listed as a recipient of a message (e.g. via the Cc:
-          header) will also get a copy from Mailman.
+          address specifies whether or not the address is displayed in
+          the list roster. Acknowledge the member's posting controls
+          whether or not Mailman sends an acknowledgement to a member
+          when they post a message to the list. Do not send a copy of a
+          member's own post specifies whether a member posting to the
+          list will get a copy of their own posting. Filter out duplicate
+          messages to list members (if possible) specifies whether
+          members who are explicitly listed as a recipient of a message
+          (e.g. via the Cc: header) will also get a copy from Mailman.
 
           Of course, members can always override these defaults by making
           changes on their membership options page.
 
    administrivia
           This option specifies whether Mailman will search posted
-          messages for admimistrivia, in other words, email commands which
-          usually should be posted to the -request address for the list.
-          Setting this to Yes helps prevent such things as unsubscribe
-          messages getting erroneously posted to the list.
+          messages for admimistrivia, in other words, email commands
+          which usually should be posted to the -request address for the
+          list. Setting this to Yes helps prevent such things as
+          unsubscribe messages getting erroneously posted to the list.
 
           If a message seems to contain administrivia, it is held for
           moderator approval.
 
    max_message_size
-          This option specifies a maximum message size, in kilobytes, over
-          which the message will be held for moderator approval.
+          This option specifies a maximum message size, in kilobytes,
+          over which the message will be held for moderator approval.
 
    host_name
-          This option specifies the host name part of email addresses used
-          by this list. For example, this is the example.com part of the
-          posting address mylist@example.com.
+          This option specifies the host name part of email addresses
+          used by this list. For example, this is the example.com part of
+          the posting address mylist@example.com.
 
           It's generally not a good idea to change this value, since its
           default value is specified when the mailing list is created.
           Changing this to an incorrect value could make it difficult to
           contact your mailing list. Also not that the url used to visit
           the list's pages is not configurable through the web interface.
-          This is because if you messed it up, you'd have to have the site
-          administrator fix it.
+          This is because if you messed it up, you'd have to have the
+          site administrator fix it.
 
    include_rfc2369_headers
           RFC 2369 is an internet standard that describes a bunch of
           headers that mailing list managers should add to messages to
           make it easier for people to interact with the list. Mail
-          reading programs which support this standard may provide buttons
-          for easy access to the list's archives, or for subscribing and
-          unsubscribing to the list. It's generally a good idea to enable
-          these headers as it provides for an improved user experience.
-          These headers are often called the List-* headers.
+          reading programs which support this standard may provide
+          buttons for easy access to the list's archives, or for
+          subscribing and unsubscribing to the list. It's generally a
+          good idea to enable these headers as it provides for an
+          improved user experience. These headers are often called the
+          List-* headers.
 
           However, not all mail readers are standards compliant yet, and
           if you have a large number of members who are using
           non-compliant mail readers, they may be annoyed at these
           headers. You should first try to educate your members as to why
-          these headers exist, and how to hide them in their mail clients.
-          As a last resort you can disable these headers, but this is not
-          recommended.
+          these headers exist, and how to hide them in their mail
+          clients. As a last resort you can disable these headers, but
+          this is not recommended.
 
    include_list_post_header
           The List-Post: header is one of the headers recommended by RFC
           2369. However for some announce-only mailing lists, only a very
           select group of people are allowed to post to the list; the
-          general membership is usually not allowed to post to such lists.
-          For lists of this nature, the List-Post: header is misleading.
-          Select No to disable the inclusion of this header. (This does
-          not affect the inclusion of the other List-* headers.)
+          general membership is usually not allowed to post to such
+          lists. For lists of this nature, the List-Post: header is
+          misleading. Select No to disable the inclusion of this header.
+          (This does not affect the inclusion of the other List-*
+          headers.)
 
 2.2 The Passwords Category
 
@@ -586,9 +591,9 @@ Contents
    list owner role is described here as the list administrator. You can
    set the list owner's password by entering it in the password field on
    the left. You must type it twice for confirmation. Note that if you
-   forget this password, the only way for you to get back into your list's
-   administrative pages is to ask the site administrator to reset it for
-   you (there's no password reminders for list owners).
+   forget this password, the only way for you to get back into your
+   list's administrative pages is to ask the site administrator to reset
+   it for you (there's no password reminders for list owners).
 
    If you want to delegate list moderation to someone else, you can enter
    a different moderator password in the field on the right (typed twice
@@ -603,7 +608,8 @@ Contents
 
    Mailman is multilingual and internationalized, meaning you can set up
    your list so that members can interact with it in any of a number of
-   natural languages. Of course, Mailman won't translate list postings. :)
+   natural languages. Of course, Mailman won't translate list postings.
+   :)
 
    However, if your site administrator has enabled its support, you can
    set your list up to support any of about two dozen languages, such as
@@ -628,8 +634,8 @@ Contents
           This set of checkboxes contains all the natural languages that
           your site administrator has made available to your mailing
           lists. Select any language that you'd either like your members
-          to be able to view the list in, or that you'd like to be able to
-          use in your list's preferred_language variable.
+          to be able to view the list in, or that you'd like to be able
+          to use in your list's preferred_language variable.
 
    encode_ascii_prefixes
           If your mailing list's preferred language uses a non-ASCII
@@ -668,33 +674,33 @@ Contents
    Mailman delivers messages to users via two modes. List members can
    elect to receive postings in bundles call digests one or a few times a
    day, or they can receive messages immediately whenever the message is
-   posted to the list. This latter delivery mode is also called non-digest
-   delivery. There are two administrative categories available for
-   separately controlling digest and non-digest delivery. You can even
-   disable one or the other forms of delivery (but not both).
-
-   Both kinds of delivery can have list-specific headers and footers added
-   to them which can contain other useful information you want your list
-   members to see. For example, you can include instructions for
+   posted to the list. This latter delivery mode is also called
+   non-digest delivery. There are two administrative categories available
+   for separately controlling digest and non-digest delivery. You can
+   even disable one or the other forms of delivery (but not both).
+
+   Both kinds of delivery can have list-specific headers and footers
+   added to them which can contain other useful information you want your
+   list members to see. For example, you can include instructions for
    unsubscribing, or a url to the lists digest, or any other information.
 
    Non-digest deliveries can also be personalized which means certain
    parts of the message can contain information tailored to the member
    receiving the message. For example, the To: header will contain the
    address of the member when deliveries are personalized. Footers and
-   headers can contain personalized information as well, such as a link to
-   the individual user's options page.
+   headers can contain personalized information as well, such as a link
+   to the individual user's options page.
 
    In addition, personalized messages will contain extra information that
    Mailman can use to unambiguously track bounces from members.
-   Ordinarily, Mailman does some pattern recognition on bounce messages to
-   determine list members whose addresses are no longer valid, but because
-   of the vagaries of mail systems, and the countless forwards people can
-   put in place, it's often the case that bounce messages don't contain
-   any useful information in them. Personalized messages avoid this
-   problem by encoding information in certain headers that unambiguously
-   identify the recipient of a message. If that message bounces, Mailman
-   will know exactly which member it was intended for.
+   Ordinarily, Mailman does some pattern recognition on bounce messages
+   to determine list members whose addresses are no longer valid, but
+   because of the vagaries of mail systems, and the countless forwards
+   people can put in place, it's often the case that bounce messages
+   don't contain any useful information in them. Personalized messages
+   avoid this problem by encoding information in certain headers that
+   unambiguously identify the recipient of a message. If that message
+   bounces, Mailman will know exactly which member it was intended for.
 
    Note that because personalization requires extra system resources, it
    must be enabled by the site administrator before you can choose it.
@@ -703,20 +709,21 @@ Contents
 
    nondigestable
           This option controls whether members can receive immediate
-          delivery or not. If not, they will be forced to receive messages
-          in digests. You can't disable non-digest delivery if digests are
-          already disabled.
+          delivery or not. If not, they will be forced to receive
+          messages in digests. You can't disable non-digest delivery if
+          digests are already disabled.
 
    personalize
           This option turns on message personalization.
 
    msg_header
           This text box lets you enter information that will be included
-          in the header of every non-digest message sent through the list.
+          in the header of every non-digest message sent through the
+          list.
 
-          See below for more information on what can go in the headers and
-          footers. If you leave this text box empty, no header will be
-          added.
+          See below for more information on what can go in the headers
+          and footers. If you leave this text box empty, no header will
+          be added.
 
    msg_footer
           Just like with the header, you can add a footer to every
@@ -724,12 +731,12 @@ Contents
 
    Headers and footers can contain any text you want. For non-English
    lists, the headers and footers can contain any character in the
-   character set of the list's preferred language. The headers and footers
-   can also contain substitution variables which Mailman will fill in with
-   information taken from the mailing list. These substitutions are in
-   Python string interpolation format, where something like %(list_name)s
-   is substituted with he name of the mailing list. Note that the trailing
-   "s" is required^2.
+   character set of the list's preferred language. The headers and
+   footers can also contain substitution variables which Mailman will
+   fill in with information taken from the mailing list. These
+   substitutions are in Python string interpolation format, where
+   something like %(list_name)s is substituted with he name of the
+   mailing list. Note that the trailing "s" is required^2.
 
    For example, a footer containing the following text:
 
@@ -745,20 +752,21 @@ Description: An example of Mailman mailing lists
    and footers:
 
    real_name
-          This is the value of the real_name configuration variable in the
-          General options category.
+          This is the value of the real_name configuration variable in
+          the General options category.
 
    list_name
           This is the canonical name of the mailing list. In other words
           it's the posting address of the list^3.
 
    host_name
-          This is the domain name part of the email address for this list.
+          This is the domain name part of the email address for this
+          list.
 
    web_page_url
-          This is the base url for contacting the list via the web. It can
-          be appended with listinfo/%(list_name)s to yield the general
-          list information page for the mailing list.
+          This is the base url for contacting the list via the web. It
+          can be appended with listinfo/%(list_name)s to yield the
+          general list information page for the mailing list.
 
    description
           The brief description of the mailing list.
@@ -768,8 +776,8 @@ Description: An example of Mailman mailing lists
 
    cgiext
           This is the extension added to CGI scripts. It might be the
-          empty string, .cgi, or something else depending on how your site
-          is configured.
+          empty string, .cgi, or something else depending on how your
+          site is configured.
 
    Note that real_name, host_name, description, and info substitution
    variables take their values from the list configuration variables of
@@ -804,27 +812,27 @@ Description: An example of Mailman mailing lists
    since they will receive fewer messages.
 
    Mailman supports two standard digest formats, and if digests are
-   enabled, users can select which of the two formats they receive. One is
-   MIME digests, where each message is an attachment inside a
+   enabled, users can select which of the two formats they receive. One
+   is MIME digests, where each message is an attachment inside a
    multipart/digest. This format also contains a summary table of
    contents, and of course the an optional header and footer, and it
    retains most of the headers of the original messages.
 
    The second type is called ``plaintext'' digests because they are
-   readable in mail readers that don't support MIME. Actually, they adhere
-   to the RFC 1153 digest standard. The retain some, but not all of the
-   original messages, but can also include a summary and headers and
-   footers.
+   readable in mail readers that don't support MIME. Actually, they
+   adhere to the RFC 1153 digest standard. The retain some, but not all
+   of the original messages, but can also include a summary and headers
+   and footers.
 
    Like non-digest delivery, you can enable or disable digest delivery,
    but you cannot disable both types of delivery. You can specify
-   different headers and footers for digest and non-digest deliveries. You
-   cannot personalize digest deliveries.
+   different headers and footers for digest and non-digest deliveries.
+   You cannot personalize digest deliveries.
 
    As list administrator, you may want to send an urgent message to all
    list members, bypassing the normal digest bundling. To do this, send
-   the message with a Urgent: header, where the value of the header is the
-   list administrator's password. Non-digest members will receive the
+   the message with a Urgent: header, where the value of the header is
+   the list administrator's password. Non-digest members will receive the
    message like normal, but digest members will receive the message
    immediately^5.
 
@@ -837,13 +845,14 @@ Description: An example of Mailman mailing lists
           are already disabled.
 
    digest_is_default
-          Controls which style of delivery is the default for new members.
-          You can choose Regular (non-digest) or Digest delivery.
+          Controls which style of delivery is the default for new
+          members. You can choose Regular (non-digest) or Digest
+          delivery.
 
    mime_is_default_digest
-          If a member is allowed to choose digests, this variable controls
-          which is the default digest style they will receive. Plain
-          digests are RFC 1153 format as described above.
+          If a member is allowed to choose digests, this variable
+          controls which is the default digest style they will receive.
+          Plain digests are RFC 1153 format as described above.
 
    digest_size_threshold
           Normally, digest members get at least one message per day, if
@@ -864,8 +873,8 @@ Description: An example of Mailman mailing lists
 
    digest_header
           This text box lets you enter information that will be included
-          in the header of every digest message sent through the list. The
-          same information can go in this header as can go in the
+          in the header of every digest message sent through the list.
+          The same information can go in this header as can go in the
           msg_header, except for the personalization variables.
 
    digest_footer
@@ -893,9 +902,9 @@ Description: An example of Mailman mailing lists
 
    The Privacy category lets you control how much of the list's
    information is public, as well as who can send messages to your list.
-   It also contains some spam detection filters. Note that this section is
-   not used to control whether your list's archives are public or private;
-   for that, use the category.
+   It also contains some spam detection filters. Note that this section
+   is not used to control whether your list's archives are public or
+   private; for that, use the category.
 
    There are four sub-categories:
      * Subscription rules - i.e. the rules for joining and leaving your
@@ -906,14 +915,14 @@ Description: An example of Mailman mailing lists
      * Spam filters - some regular expression based rules for header
        matching
 
-   The sender, recipient, and spam filtering rules are part of the general
-   list moderation features of Mailman. When a message is posted to the
-   list, it is matched against a number of criteria, the outcome of which
-   determines whether the message is reflected to the membership or not.
-   In general, the outcome is one of four states:
+   The sender, recipient, and spam filtering rules are part of the
+   general list moderation features of Mailman. When a message is posted
+   to the list, it is matched against a number of criteria, the outcome
+   of which determines whether the message is reflected to the membership
+   or not. In general, the outcome is one of four states:
 
-     * Approved or Accepted - the message may be sent on to the members of
-       the mailing list.
+     * Approved or Accepted - the message may be sent on to the members
+       of the mailing list.
      * Hold - the message will be held for moderator approval. The list
        owners and moderators will then have to explicitly approve the
        message before the list members will see it.
@@ -948,37 +957,38 @@ Description: An example of Mailman mailing lists
           join the list. The available options may differ based on some
           defaults that the site administrator chooses. They are:
 
-          + None - No verification is done on the subscribing member. This
-            is also called open subscriptions and is generally disabled by
-            default. The site administrator must allow list admins to
-            choose this option; if not, this option will not be presented
-            to you.
+          + None - No verification is done on the subscribing member.
+            This is also called open subscriptions and is generally
+            disabled by default. The site administrator must allow list
+            admins to choose this option; if not, this option will not be
+            presented to you.
           + Confirm - An email confirmation step is required before the
             address is added to the list. When a member requests
             subscription, either via the web page or by sending a message
-            to yourlist-join@example.com, Mailman will send a confirmation
-            message to the requesting address. This mail-back confirmation
-            contains a unique identifier, which the requester can present
-            to Mailman in order to confirm their subscription. This can be
-            done either by replying to the mail-back, or by visiting the
-            url in the mail-back message. The url points to a page that
-            lets the user either discard or confirm their request.
+            to yourlist-join@example.com, Mailman will send a
+            confirmation message to the requesting address. This
+            mail-back confirmation contains a unique identifier, which
+            the requester can present to Mailman in order to confirm
+            their subscription. This can be done either by replying to
+            the mail-back, or by visiting the url in the mail-back
+            message. The url points to a page that lets the user either
+            discard or confirm their request.
           + Require approval - All subscription requests are held for
             approval of the list moderator. No mail-back confirmation is
             sent, but the list admins will recieve a message indicating
             that approval is pending.
           + Confirm and approve - Here, a mail-back notice must first be
-            confirmed by the requester. Once confirmed, the list moderator
-            must then approve the request. This is the most secure method
-            for users to subscribe since it both verifies the requesting
-            address, and forces the list moderators to approve the
-            request.
+            confirmed by the requester. Once confirmed, the list
+            moderator must then approve the request. This is the most
+            secure method for users to subscribe since it both verifies
+            the requesting address, and forces the list moderators to
+            approve the request.
 
    unsubscribe_policy
           Specifies whether the list moderator's approval is required for
           unsubscription requests. No is highly recommended, since it is
-          exceedingly impolite to not allow people to leave a mailing list
-          whenever they want (i.e. opt-out). Yes is useful in some
+          exceedingly impolite to not allow people to leave a mailing
+          list whenever they want (i.e. opt-out). Yes is useful in some
           specialized contexts; e.g. you may not want to allow employees
           to unsubscribe from the company newsletter.
 
@@ -1003,8 +1013,8 @@ Description: An example of Mailman mailing lists
    obscure_addresses
           Controls whether some simple obfuscation of addresses is used
           when member addresses are included on web pages. This should
-          reduce the opportunity for email address harvesting by spammers,
-          although it probably doesn't eliminate it.
+          reduce the opportunity for email address harvesting by
+          spammers, although it probably doesn't eliminate it.
 
   2.7.2 Sender filters
 
@@ -1014,20 +1024,20 @@ Description: An example of Mailman mailing lists
    non-members.
 
    default_member_moderation
-          Member postings are held for moderation if their moderation flag
-          is turned on. Note that only the list administrators can change
-          the value of a member's moderation flag.
+          Member postings are held for moderation if their moderation
+          flag is turned on. Note that only the list administrators can
+          change the value of a member's moderation flag.
 
           You can control whether new members get their moderation flag
           turned on or off by default when they subscribe to the list. By
           turning this flag off by default, postings by members will be
-          allowed without further intervention (barring other restrictions
-          such as size or implicit recipient lists - see below). By
-          turning the flag on, you can quarantine new member postings to
-          make sure that they meet your criteria for netiquette,
-          topicality, etc. Once you determine that the new member
-          understands the community's posting rules, you can turn off
-          their moderation flag and let their postings go through
+          allowed without further intervention (barring other
+          restrictions such as size or implicit recipient lists - see
+          below). By turning the flag on, you can quarantine new member
+          postings to make sure that they meet your criteria for
+          netiquette, topicality, etc. Once you determine that the new
+          member understands the community's posting rules, you can turn
+          off their moderation flag and let their postings go through
           unstopped.
 
           E-newsletter style lists can also be set up by using the
@@ -1046,9 +1056,9 @@ Description: An example of Mailman mailing lists
           to Reject or Discard.
 
           Note that when a moderated member posts to your list, and the
-          member_moderation_action is set to Hold, the message will appear
-          on the administrative requests page. When you dispose of the
-          message, you will be given an opportunity to clear the
+          member_moderation_action is set to Hold, the message will
+          appear on the administrative requests page. When you dispose of
+          the message, you will be given an opportunity to clear the
           moderation flag at the same time. If you're quarantining new
           posts, this makes it very convenient to both approve a new
           member's post and de-moderate them at the same time.
@@ -1058,12 +1068,12 @@ Description: An example of Mailman mailing lists
           member_moderation_action is Reject, this variable contains the
           text sent in the rejection notice.
 
-   The next batch of variables controls what happens when non-members post
-   messages to the list. Each of these accepts one email address per line;
-   regular expressions are allowed if the line starts with the (caret)
-   character. These address lists are always consulted in the order in
-   which they're presented on this page (i.e. accepts first, followed by
-   holds, rejections, and discards).
+   The next batch of variables controls what happens when non-members
+   post messages to the list. Each of these accepts one email address per
+   line; regular expressions are allowed if the line starts with the
+   (caret) character. These address lists are always consulted in the
+   order in which they're presented on this page (i.e. accepts first,
+   followed by holds, rejections, and discards).
 
    accept_these_nonmembers
           Postings from non-members whose addresses match this list are
@@ -1087,18 +1097,18 @@ Description: An example of Mailman mailing lists
           the addresses of known spammers to this list.
 
    generic_nonmember_action
-          This variable controls what happens to non-member posts when the
-          address of the sender doesn't match any of the above four lists.
-          If you set this to Hold, the posting will appear on the
+          This variable controls what happens to non-member posts when
+          the address of the sender doesn't match any of the above four
+          lists. If you set this to Hold, the posting will appear on the
           administrative requests page, and you will be given an
-          opportunity to add the non-member to one of the above four lists
-          at the same time you dispose of the held message.
+          opportunity to add the non-member to one of the above four
+          lists at the same time you dispose of the held message.
 
    forward_auto_discards
-          When messages from non-members are discarded, either because the
-          sender address matched discard_these_nonmembers, or because
-          generic_nonmember_action is Discard, you can choose whether such
-          messages are forwarded to the lsit administrators or not.
+          When messages from non-members are discarded, either because
+          the sender address matched discard_these_nonmembers, or because
+          generic_nonmember_action is Discard, you can choose whether
+          such messages are forwarded to the lsit administrators or not.
 
   2.7.3 Recipient Filters
 
@@ -1108,17 +1118,17 @@ Description: An example of Mailman mailing lists
    require_explicit_destination
           This controls whether the mailing list posting address must be
           explicitly named in the To: or Cc: recipient lists. The main
-          reason why it wouldn't is if the message was blind-carbon-copied
-          (i.e. Bcc:'d) to the list. Spammers like to do this, but
-          sometimes legitimate messages are forwarded to the list this
-          way.
+          reason why it wouldn't is if the message was
+          blind-carbon-copied (i.e. Bcc:'d) to the list. Spammers like to
+          do this, but sometimes legitimate messages are forwarded to the
+          list this way.
 
           If the list is not explicitly addressed and this setting is
           turned on, the message will be held for moderator approval.
 
    acceptable_aliases
-          This is the list of alternative addresses that are acceptable as
-          a list posting address when require_explicit_destination is
+          This is the list of alternative addresses that are acceptable
+          as a list posting address when require_explicit_destination is
           enabled. This is useful for when there aliases for the main
           posting address (e.g. help@example.com may be an alias for
           help-list@example.com).
@@ -1135,20 +1145,21 @@ Description: An example of Mailman mailing lists
    replace dedicated anti-spam tools such as SpamAssassin or Spambayes.
 
    bounce_matching_headers
-          This variable contains header regular expressions, one per line,
-          and if any of a message's headers matches one of these patterns,
-          it will be held for moderation. The format is a colon separated
-          header and value, where the header is case insensitive and the
-          value is any valid Python regular expression. Lines that start
-          with # are ignored.
+          This variable contains header regular expressions, one per
+          line, and if any of a message's headers matches one of these
+          patterns, it will be held for moderation. The format is a colon
+          separated header and value, where the header is case
+          insensitive and the value is any valid Python regular
+          expression. Lines that start with # are ignored.
 
           This variable can be used to catch known spammers by writing
           regexps that match against To: or Cc: lines, or known-bad
-          Message-ID:s. Perhaps more useful though are patterns that match
-          headers added by spam detection tools higher up in the tool
-          chain. For example, you might configure SpamAssassin to add an
-          X-Spam-Score: header with between zero and 5 stars depending on
-          the spam score. Then you can add a line to this variable like:
+          Message-ID:s. Perhaps more useful though are patterns that
+          match headers added by spam detection tools higher up in the
+          tool chain. For example, you might configure SpamAssassin to
+          add an X-Spam-Score: header with between zero and 5 stars
+          depending on the spam score. Then you can add a line to this
+          variable like:
 
     X-Spam-Score: [*]{3,5}
 
@@ -1161,35 +1172,35 @@ Description: An example of Mailman mailing lists
    Mailman. Here's an overview of how it works:
 
    When a bounce is received, Mailman tries to extract two pieces of
-   information from the message: the address of the member the message was
-   intended for, and the severity of the problem causing the bounce. The
-   severity can be either hard for fatal errors, or soft for transient
-   errors. When in doubt, a hard severity is used.
+   information from the message: the address of the member the message
+   was intended for, and the severity of the problem causing the bounce.
+   The severity can be either hard for fatal errors, or soft for
+   transient errors. When in doubt, a hard severity is used.
 
    If no member address can be extracted from the bounce, then the bounce
    message is usually discarded. Every member has a bounce score,
-   initialized at zero, and every time we encounter a bounce from a member
-   we increment that member's score. Hard bounces increment by 1 while
-   soft bounces increment by 0.5. We only increment the bounce score once
-   per day, so even if we receive ten hard bounces from a member per day,
-   their score will increase by only 1 for that day.
-
-   When a member's bounce score is greater than the bounce score threshold
-   (see below), the member's subscription is disabled. Once disabled, the
-   member will not receive any postings from the list until their
-   membership is explicitly re-enabled, either by the list administrator
-   or the user. However, they will receive occasional reminders that their
-   membership has been disabled, and these reminders will include
-   information about how to re-enable their membership. You can control
-   both the number of reminders the member will receive and the frequency
-   with which these reminders are sent.
+   initialized at zero, and every time we encounter a bounce from a
+   member we increment that member's score. Hard bounces increment by 1
+   while soft bounces increment by 0.5. We only increment the bounce
+   score once per day, so even if we receive ten hard bounces from a
+   member per day, their score will increase by only 1 for that day.
+
+   When a member's bounce score is greater than the bounce score
+   threshold (see below), the member's subscription is disabled. Once
+   disabled, the member will not receive any postings from the list until
+   their membership is explicitly re-enabled, either by the list
+   administrator or the user. However, they will receive occasional
+   reminders that their membership has been disabled, and these reminders
+   will include information about how to re-enable their membership. You
+   can control both the number of reminders the member will receive and
+   the frequency with which these reminders are sent.
 
    There is one other important configuration variable; after a certain
-   period of time - during which no bounces from the member are received -
-   the bounce information is considered stale and discarded. Thus by
+   period of time - during which no bounces from the member are received
+   - the bounce information is considered stale and discarded. Thus by
    adjusting this value, and the score threshold, you can control how
-   quickly bouncing members are disabled. You should tune both of these to
-   the frequency and traffic volume of your list.
+   quickly bouncing members are disabled. You should tune both of these
+   to the frequency and traffic volume of your list.
 
    bounce_processing
           Specifies whether or not this list should do automatic bounce
@@ -1198,8 +1209,8 @@ Description: An example of Mailman mailing lists
    bounce_score_threshold
           This is the bounce score above which a member's subscription
           will be automatically disabled. When the subscription is
-          re-enabled, their bounce score will be reset to zero. This value
-          can be a floating point number.
+          re-enabled, their bounce score will be reset to zero. This
+          value can be a floating point number.
 
    bounce_info_stale_after
           Thenumber of days after which a member's bounce information is
@@ -1222,8 +1233,8 @@ Description: An example of Mailman mailing lists
           discarded, or forwarded on the list administrator. The bounce
           detector isn't perfect, although personalization can make it
           much more accurate. The list owner may want to receive
-          unrecognized bounces so that they can manually disable or remove
-          such members.
+          unrecognized bounces so that they can manually disable or
+          remove such members.
 
    bounce_notify_owner_on_disable
           This option controls whether or not the list owner is notified
@@ -1250,22 +1261,22 @@ Description: An example of Mailman mailing lists
           archived, on an individual per-message basis. If the posted
           message has a X-No-Archive: header (regardless of value), or a
           X-Archive: header with a value of No (case insensitive), then
-          the message will not be archived, although it will be treated as
-          normal in all other ways.
+          the message will not be archived, although it will be treated
+          as normal in all other ways.
 
    archive_private
           Controls whether Pipermail archives are private or public.
-          Private archives require a valid member address and password, or
-          a list administrator password in order to access them. This
+          Private archives require a valid member address and password,
+          or a list administrator password in order to access them. This
           option has no effect when a third party archiver is used.
 
    archive_volume_frequency
           Controls how Pipermail splits messages in the archive. The most
-          common option is Monthly meaning a new archive volume is started
-          every month. Very high volume lists may want a shorter frequency
-          (e.g. Weekly or Daily) where as lower volume lists may want a
-          longer frequency (e.g. Yearly). This option has no effect when a
-          third party archiver is used.
+          common option is Monthly meaning a new archive volume is
+          started every month. Very high volume lists may want a shorter
+          frequency (e.g. Weekly or Daily) where as lower volume lists
+          may want a longer frequency (e.g. Yearly). This option has no
+          effect when a third party archiver is used.
 
 2.10 The Mail/News Gateway Category
 
@@ -1289,7 +1300,8 @@ Description: An example of Mailman mailing lists
 
                              1 This is an Appendix
 
-   To create an appendix in a Python HOWTO document, use markup like this:
+   To create an appendix in a Python HOWTO document, use markup like
+   this:
 
 \appendix
 
@@ -1304,7 +1316,7 @@ Just add another \section{}, but don't say \appendix again.
 
                             About this document ...
 
-   GNU Mailman - List Administration Manual, December 5, 2007, Release 2.1
+   GNU Mailman - List Administration Manual, April 21, 2008, Release 2.1
 
    This document was generated using the LaTeX2HTML translator.
 
@@ -1316,7 +1328,7 @@ Just add another \section{}, but don't say \appendix again.
    The application of LaTeX2HTML to the Python documentation has been
    heavily tailored by Fred L. Drake, Jr. Original navigation icons were
    contributed by Christopher Petrilli.
-     __________________________________________________________________
+     _________________________________________________________________
 
     Footnotes
 
@@ -1338,15 +1350,15 @@ Just add another \section{}, but don't say \appendix again.
           user_delivered_to is used, but it's important to remember that
           they can be different. When they're different, Mailman always
           uses the lower case address as the key to the member's
-          subscription information, but it always delivers messages to the
-          case-preserved version.
+          subscription information, but it always delivers messages to
+          the case-preserved version.
 
    ... immediately^5
           They'll also receive the message in the digest.
-     __________________________________________________________________
+     _________________________________________________________________
 
    Previous Page Up one Level Next Page GNU Mailman - List Administration
-                                                     Manual
-     __________________________________________________________________
+                                   Manual
+     _________________________________________________________________
 
-   Release 2.1, documentation updated on December 5, 2007.
+   Release 2.1, documentation updated on April 21, 2008.