This commit was manufactured by cvs2svn to create branch

'Release_2_1-maint'.

5 files changed, 695 insertions, 0 deletions

diff --git a/admin/www/jwzrebuttal.ht b/admin/www/jwzrebuttal.ht
new file mode 100644
index 00000000..74b9212a
--- /dev/null
+++ b/admin/www/jwzrebuttal.ht
@@ -0,0 +1,88 @@
+Title: Mailman Considered Beneficial
+Author: Barry Warsaw
+Author-email: barry@python.org
+Links: links.h rant-links.h
+
+<h3>Mailman Considered Beneficial</h3>
+
+Jamie Zawinski posted an article in 2002 titled <a
+href="http://www.jwz.org/doc/mailman.html">Mailman Considered
+Harmful</a>.  I know Jamie and respect him, but I respectfully
+disagree with his assessment.  You'd be worried if I didn't, eh?
+
+<p>To give Jamie the benefit of the doubt, I believe he was reviewing
+older versions of the Mailman software, where some of his complaints
+may have been appropriate.  Here is a rebuttal to his
+article, based on
+<a href="http://sourceforge.net/project/showfiles.php?group_id=103">the
+latest stable release of Mailman 2.1</a>, unless otherwise specified.
+
+<h4>Mailman is a pain in the ass for the end user.</h4>
+
+Jamie must have reviewed a pre-2.0 version, because Mailman releases
+since 2.0 have implemented the "sane" recipe.  Indeed it would be
+insane not to.  I may be mad, but I'm not insane.  In fact, in Mailman
+2.1, there are several ways to get unsubscribed, any one of which will
+work just fine:
+
+<ul>
+    <li>Send a message to <em>list</em>-leave or <em>list</em>-unsubscribe and
+        reply to the confirmation message.  It doesn't matter at all what
+        is in your original message.
+    <li>Mail "unsubscribe" to the <em>list</em>-request address and
+        reply to the confirmation message.
+    <li>Use a mail reader that understands the standard
+        <a href="http://www.faqs.org/rfcs/rfc2369.html">RFC 2369</a>
+        List-Unsubscribe header, then just click on that header and
+        reply to the confirmation message.
+    <li>Visit your <em>user's options page</em>, click on the
+        Unsubscribe button and reply to the confirmation message.
+        Note that with Mailman 2.1, mailing lists can be personalized,
+        which means the url to your options page can be included in
+        the footer of every message you get from the list (digests
+        currently excluded).
+</ul>
+
+What could be simpler?
+
+<h4>Mailman's password mechanism provides zero security.</h4>
+
+I disagree with Jamie about the utility of Mailman's passwords because
+in general they do prevent malicious people from changing your
+subscription options out from under you.  But I will also concede that
+he has a point about password management by naive users, so you should
+know that it is trivial to disable monthly password reminders, either
+on a list-wide basis or on a per-user basis.
+
+<p>Monthly password reminders serve additional purposes though: they
+remind you of lists you are on which you may have forgotten about,
+they remind you about how to get unsubscribed from such lists, and
+they offer an opportunity for lists to cull their membership of
+non-functioning addresses.  In Mailman 2.1, the monthly reminders can
+be sent out with <a
+href="http://cr.yp.to/proto/verp.txt">VERP</a>-like envelopes, Mailman
+can unambiguously parse any bounces from dead addresses, and can use
+this information to automatically disable or delete disappeared
+members.
+
+<p>When you subscribe to a mailing list, the password is completely
+optional -- omit it and Mailman generates a random one for you.  You
+generally don't need to know your password except if you want to
+change your delivery options, e.g. to temporarily disable delivery
+while you're on vacation, or to switch to digest delivery, subscribe
+to topics, etc.  For simple membership management (subscribing and
+unsubscribing), you never need to know it.  The user options
+<b>are</b> useful.
+
+<h4>Web-based subscriptions</h4>
+
+If all you care about is web-based subscriptions, then yes it's pretty
+easy to set up a simple CGI to do this.  It's just as easy to do with
+Mailman as any other mailing list software.  Note though, that
+Mailman's web interface is much more sophisticated because you can do
+nearly all the list configuration through the web.  Okay, this is of
+primary benefit for list owners rather than list members, and Jamie's
+rant is focused on the member experience.  Note though, that Mailman's
+subscription page also gives the user the option of selecting a
+default language (for multilingual lists) and their preferred delivery
+mechanism (digests or regular delivery).
diff --git a/admin/www/jwzrebuttal.html b/admin/www/jwzrebuttal.html
new file mode 100644
index 00000000..b3d86fcc
--- /dev/null
+++ b/admin/www/jwzrebuttal.html
@@ -0,0 +1,228 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<!-- THIS PAGE IS AUTOMATICALLY GENERATED.  DO NOT EDIT. -->
+<!-- Sun Mar 23 00:31:21 2003 -->
+<!-- USING HT2HTML 2.0 -->
+<!-- SEE http://ht2html.sf.net -->
+<!-- User-specified headers:
+Title: Mailman Considered Beneficial
+
+-->
+
+<head>
+<title>Mailman Considered Beneficial</title>
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+<meta name="generator" content="HT2HTML/2.0">
+<style type="text/css">
+body { margin: 0px; }
+</style>
+</head>
+<body bgcolor="#ffffff" text="#000000"
+      marginwidth="0" marginheight="0"
+      link="#0000bb"  vlink="#551a8b"
+      alink="#ff0000">
+<!-- start of page table -->
+<table width="100%" border="0" cellspacing="0" cellpadding="0">
+<!-- start of banner row -->
+<tr>
+<!-- start of corner cells -->
+<td width="150" valign="middle" bgcolor="white" class="corner">
+
+<center>
+    <a href="./index.html">
+    <img border=0 src="./images/logo-70.jpg"></a></center> </td>
+<td width="15" bgcolor="#eecfa1">&nbsp;&nbsp;</td><!--spacer-->
+<!-- end of corner cells -->
+<!-- start of banner -->
+<td width="90%" bgcolor="#eecfa1" class="banner">
+<!-- start of site links table -->
+<table width="100%" border="0"
+CELLSPACING=0 CELLPADDING=0
+       bgcolor="#ffffff">
+<tr>
+    <td bgcolor="#eecfa1">
+<a href="./index.html">Home</a>
+    </td>
+    <td bgcolor="#eecfa1">
+<a href="./docs.html">Documentation</a>
+    </td>
+    <td bgcolor="#eecfa1">
+<a href="./lists.html">Mailing lists</a>
+    </td>
+</tr><tr>
+    <td bgcolor="#eecfa1">
+<a href="./help.html">Help</a>
+    </td>
+    <td bgcolor="#eecfa1">
+<a href="./download.html">Download</a>
+    </td>
+    <td bgcolor="#eecfa1">
+<a href="./devs.html">Developers</a>
+    </td>
+</tr>
+</table><!-- end of site links table -->
+
+</td><!-- end of banner -->
+</tr><!-- end of banner row -->
+<tr><!-- start of sidebar/body row -->
+<!-- start of sidebar cells -->
+<td width="150" valign="top" bgcolor="#eecfa1" class="sidebar">
+<!-- start of sidebar table -->
+<table width="100%" border="0" cellspacing="0" cellpadding="3"
+       bgcolor="#ffffff">
+<tr><td bgcolor="#36648b"><b><font color="#ffffff">
+Overview
+</font></b></td></tr>
+<tr><td bgcolor="#eecfa1">
+<a href="index.html">Home</a>
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+<a href="features.html">Features</a>
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+<a href="i18n.html">Internationalization</a>
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+<a href="otherstuff.html">Rants, Papers, and Logos</a>
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+<a href="inthenews.html">Mailman in Use</a>
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+<a href="prev.html">Previous Releases</a>
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+<a href="bugs.html">Bugs and Patches</a>
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+<a href="mirrors.html">Mirrors</a>
+</td></tr>
+<tr><td bgcolor="#eecfa1">&nbsp;
+<tr><td bgcolor="#36648b"><b><font color="#ffffff">
+Rants
+</font></b></td></tr>
+<tr><td bgcolor="#eecfa1">
+<b>Mailman Considered Beneficial</b>
+</td></tr>
+<tr><td bgcolor="#eecfa1">&nbsp;
+<tr><td bgcolor="#36648b"><b><font color="#ffffff">
+Email Us
+</font></b></td></tr>
+<tr><td bgcolor="#eecfa1">
+<a href="mailto:barry@python.org">Barry Warsaw</a>
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+&nbsp;
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+<a href="http://www.python.org/"><img border=0
+                          src="./images/PythonPoweredSmall.png"
+                          ></a>&nbsp;<a href="http://sourceforge.net"><img 
+                          src="http://sourceforge.net/sflogo.php?group_id=103"
+                          width="88" height="31" border="0"
+                          alt="SourceForge Logo"></a>
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+&nbsp;
+</td></tr>
+<tr><td bgcolor="#eecfa1">
+&copy; 1998-2003
+Free Software Foundation, Inc.  Verbatim copying and distribution of this
+entire article is permitted in any medium, provided this notice is preserved.
+
+</td></tr>
+</table><!-- end of sidebar table -->
+
+</td>
+<td width="15">&nbsp;&nbsp;</td><!--spacer-->
+<!-- end of sidebar cell -->
+<!-- start of body cell -->
+<td valign="top" width="90%" class="body"><br>
+<h3>Mailman Considered Beneficial</h3>
+
+Jamie Zawinski posted an article in 2002 titled <a
+href="http://www.jwz.org/doc/mailman.html">Mailman Considered
+Harmful</a>.  I know Jamie and respect him, but I respectfully
+disagree with his assessment.  You'd be worried if I didn't, eh?
+
+<p>To give Jamie the benefit of the doubt, I believe he was reviewing
+older versions of the Mailman software, where some of his complaints
+may have been appropriate.  Here is a rebuttal to his
+article, based on
+<a href="http://sourceforge.net/project/showfiles.php?group_id=103">the
+latest stable release of Mailman 2.1</a>, unless otherwise specified.
+
+<h4>Mailman is a pain in the ass for the end user.</h4>
+
+Jamie must have reviewed a pre-2.0 version, because Mailman releases
+since 2.0 have implemented the "sane" recipe.  Indeed it would be
+insane not to.  I may be mad, but I'm not insane.  In fact, in Mailman
+2.1, there are several ways to get unsubscribed, any one of which will
+work just fine:
+
+<ul>
+    <li>Send a message to <em>list</em>-leave or <em>list</em>-unsubscribe and
+        reply to the confirmation message.  It doesn't matter at all what
+        is in your original message.
+    <li>Mail "unsubscribe" to the <em>list</em>-request address and
+        reply to the confirmation message.
+    <li>Use a mail reader that understands the standard
+        <a href="http://www.faqs.org/rfcs/rfc2369.html">RFC 2369</a>
+        List-Unsubscribe header, then just click on that header and
+        reply to the confirmation message.
+    <li>Visit your <em>user's options page</em>, click on the
+        Unsubscribe button and reply to the confirmation message.
+        Note that with Mailman 2.1, mailing lists can be personalized,
+        which means the url to your options page can be included in
+        the footer of every message you get from the list (digests
+        currently excluded).
+</ul>
+
+What could be simpler?
+
+<h4>Mailman's password mechanism provides zero security.</h4>
+
+I disagree with Jamie about the utility of Mailman's passwords because
+in general they do prevent malicious people from changing your
+subscription options out from under you.  But I will also concede that
+he has a point about password management by naive users, so you should
+know that it is trivial to disable monthly password reminders, either
+on a list-wide basis or on a per-user basis.
+
+<p>Monthly password reminders serve additional purposes though: they
+remind you of lists you are on which you may have forgotten about,
+they remind you about how to get unsubscribed from such lists, and
+they offer an opportunity for lists to cull their membership of
+non-functioning addresses.  In Mailman 2.1, the monthly reminders can
+be sent out with <a
+href="http://cr.yp.to/proto/verp.txt">VERP</a>-like envelopes, Mailman
+can unambiguously parse any bounces from dead addresses, and can use
+this information to automatically disable or delete disappeared
+members.
+
+<p>When you subscribe to a mailing list, the password is completely
+optional -- omit it and Mailman generates a random one for you.  You
+generally don't need to know your password except if you want to
+change your delivery options, e.g. to temporarily disable delivery
+while you're on vacation, or to switch to digest delivery, subscribe
+to topics, etc.  For simple membership management (subscribing and
+unsubscribing), you never need to know it.  The user options
+<b>are</b> useful.
+
+<h4>Web-based subscriptions</h4>
+
+If all you care about is web-based subscriptions, then yes it's pretty
+easy to set up a simple CGI to do this.  It's just as easy to do with
+Mailman as any other mailing list software.  Note though, that
+Mailman's web interface is much more sophisticated because you can do
+nearly all the list configuration through the web.  Okay, this is of
+primary benefit for list owners rather than list members, and Jamie's
+rant is focused on the member experience.  Note though, that Mailman's
+subscription page also gives the user the option of selecting a
+default language (for multilingual lists) and their preferred delivery
+mechanism (digests or regular delivery).
+
+</td><!-- end of body cell -->
+</tr><!-- end of sidebar/body row -->
+</table><!-- end of page table -->
+</body></html>
diff --git a/admin/www/rant-links.h b/admin/www/rant-links.h
new file mode 100644
index 00000000..173d7f2b
--- /dev/null
+++ b/admin/www/rant-links.h
@@ -0,0 +1,3 @@
+<!-- -*- html -*- -->
+<h3>Rants</h3>
+<li><a href="jwzrebuttal.html">Mailman Considered Beneficial</a>
diff --git a/misc/email-2.5.1.tar.gz b/misc/email-2.5.1.tar.gz
new file mode 100644
index 00000000..a6858be4
--- /dev/null
+++ b/misc/email-2.5.1.tar.gz
diff --git a/misc/sitelist.cfg b/misc/sitelist.cfg
new file mode 100644
index 00000000..511180a0
--- /dev/null
+++ b/misc/sitelist.cfg
@@ -0,0 +1,376 @@
+## "mailman" mailing list configuration settings -*- python -*-
+## captured on Sat Mar 22 00:21:06 2003
+
+## Mailman - The GNU Mailing List Management System
+## Copyright (C) 2003 Free Software Foundation, Inc.
+## 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+
+## General options
+#
+# Fundamental list characteristics, including descriptive info and basic
+# behaviors.
+
+# The capitalization of this name can be changed to make it presentable
+# in polite company as a proper noun, or to make an acronym part all
+# upper case, etc.  However, the name will be advertised as the email
+# address (e.g., in subscribe confirmation notices), so it should not be
+# otherwise altered.  (Email addresses are not case sensitive, but they
+# are sensitive to almost everything else :-)
+real_name = 'Mailman'
+
+# This description is used when the mailing list is listed with other
+# mailing lists, or in headers, and so forth.  It should be as succinct
+# as you can get it, while still identifying what the list is.
+description = 'Mailman site list'
+
+# This text will be prepended to subject lines of messages posted to the
+# list, to distinguish mailing list messages in in mailbox summaries.
+# Brevity is premium here, it's ok to shorten long mailing list names to
+# something more concise, as long as it still identifies the mailing
+# list.
+subject_prefix = '[Mailman Site List] '
+
+# List moderators (and list administrators) are sent daily reminders of
+# requests pending approval, like subscriptions to a moderated list, or
+# postings that are being held for one reason or another.  Setting this
+# option causes notices to be sent immediately on the arrival of new
+# requests as well.
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+admin_immed_notify = 1
+
+# Should administrator get notices of subscribes and unsubscribes?
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+admin_notify_mchanges = 1
+
+# Approval notices are sent when mail triggers certain of the limits
+# except routine list moderation and spam filters, for which notices are
+# not sent.  This option overrides ever sending the notice.
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+respond_to_post_requests = 1
+
+## Nondigest options
+#
+# Policies concerning immediately delivered list traffic.
+
+# Can subscribers choose to receive mail immediately, rather than in
+# batched digests?
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+nondigestable = 1
+
+# Normally, Mailman sends the regular delivery messages to the mail
+# server in batches.  This is much more efficent because it reduces the
+# amount of traffic between Mailman and the mail server.
+# 
+# However, some lists can benefit from a more personalized approach.  In
+# this case, Mailman crafts a new message for each member on the regular
+# delivery list.  Turning this feature on may degrade the performance of
+# your site, so you need to carefully consider whether the trade-off is
+# worth it, or whether there are other ways to accomplish what you want.
+# You should also carefully monitor your system load to make sure it is
+# acceptable.
+# 
+# Select No to disable personalization and send messages to the members
+# in batches.  Select Yes to personalize deliveries and allow additional
+# substitution variables in message headers and footers (see below).  In
+# addition, by selecting Full Personalization, the To header of posted
+# messages will be modified to include the member's address instead of
+# the list's posting address.
+# 
+# When personalization is enabled, a few more expansion variables that
+# can be included in the <a href="?VARHELP=nondigest/msg_header">message
+# header and message footer.
+# 
+# These additional substitution variables will be available for your
+# headers and footers, when this feature is enabled:
+# 
+# user_address - The address of the user, coerced to lower case.
+# user_delivered_to - The case-preserved address that the user is
+# subscribed with. user_password - The user's password. user_name - The
+# user's full name. user_optionsurl - The url to the user's option page.
+# 
+# 
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+#    2 = "Full Personalization"
+personalize = 1
+
+# Text appended to the bottom of every immediately-delivery message.
+# This text can include Python format strings which are resolved against
+# list attributes.  The list of substitutions allowed are:
+# 
+# 
+# real_name - The `pretty' name of the list; usually the list name with
+# capitalization.
+# 
+# list_name - The name by which the list is identified in URLs, where
+# case is significant.  (For backwards compability, _internal_name is
+# equivalent.)
+# 
+# host_name - The fully qualified domain name that the list server runs
+# on.
+# 
+# web_page_url - The base URL for Mailman.  This can be appended with,
+# e.g. listinfo/%(internal_name)s to yield the listinfo page for the
+# mailing list.
+# 
+# description - The brief description of the mailing list.
+# 
+# info - The full description of the mailing list.
+# 
+# cgiext - The extension added to CGI scripts.
+# 
+# 
+msg_footer = """_______________________________________________
+%(real_name)s site list
+%(real_name)s@%(host_name)s
+%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s"""
+
+## Digest options
+#
+# Batched-delivery digest characteristics.
+
+# Can list members choose to receive list traffic bunched in digests?
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+digestable = 0
+
+## Privacy options
+#
+# This section allows you to configure subscription and membership
+# exposure policy.  You can also control whether this list is public or
+# not.  See also the <a
+# href="http://www.wooz.org/mailman/admin/mailman/archive">Archival
+# Options</a> section for separate archive-related privacy settings.
+
+# Advertise this list when people ask what lists are on this machine?
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+advertised = 0
+
+# Confirm (*) - email confirmation required Require approval - require
+# list administrator approval for subscriptions Confirm and approve -
+# both confirm and approve
+# 
+# (*) when someone requests a subscription, Mailman sends them a notice
+# with a unique subscription request number that they must reply to in
+# order to subscribe. This prevents mischievous (or malicious) people
+# from creating subscriptions for others without their consent.
+#
+# legal values are:
+#    1 = "Confirm"
+#    2 = "Require approval"
+#    3 = "Confirm and approve"
+subscribe_policy = 2
+
+# When members want to leave a list, they will make an unsubscription
+# request, either via the web or via email. Normally it is best for you
+# to allow open unsubscriptions so that users can easily remove
+# themselves from mailing lists (they get really upset if they can't get
+# off lists!).
+# 
+# For some lists though, you may want to impose moderator approval
+# before an unsubscription request is processed.  Examples of such lists
+# include a corporate mailing list that all employees are required to be
+# members of.
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+unsubscribe_policy = 0
+
+# Addresses in this list are banned outright from subscribing to this
+# mailing list, with no further moderation required.  Add addresses one
+# per line; start the line with a ^ character to designate a regular
+# expression match.
+ban_list = []
+
+# When set, the list of subscribers is protected by member or admin
+# password authentication.
+#
+# legal values are:
+#    0 = "Anyone"
+#    1 = "List members"
+#    2 = "List admin only"
+private_roster = 2
+
+# Setting this option causes member email addresses to be transformed
+# when they are presented on list web pages (both in text and as links),
+# so they're not trivially recognizable as email addresses.  The
+# intention is to prevent the addresses from being snarfed up by
+# automated web scanners for use by spammers.
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+obscure_addresses = 1
+
+## Privacy options
+#
+# When a message is posted to the list, a series of moderation steps are
+# take to decide whether the a moderator must first approve the message
+# or not.  This section contains the controls for moderation of both
+# member and non-member postings.
+# 
+# <p>Member postings are held for moderation if their <b>moderation
+# flag</b> is turned on.  You can control whether member postings are
+# moderated by default or not.
+# 
+# <p>Non-member postings can be automatically <a
+# href="?VARHELP=privacy/sender/accept_these_nonmembers" >accepted</a>,
+# <a href="?VARHELP=privacy/sender/hold_these_nonmembers">held for
+# moderation</a>, <a
+# href="?VARHELP=privacy/sender/reject_these_nonmembers" >rejected</a>
+# (bounced), or <a
+# href="?VARHELP=privacy/sender/discard_these_nonmembers"
+# >discarded</a>, either individually or as a group.  Any posting from a
+# non-member who is not explicitly accepted, rejected, or discarded,
+# will have their posting filtered by the <a
+# href="?VARHELP=privacy/sender/generic_nonmember_action">general
+# non-member rules</a>.
+# 
+# <p>In the text boxes below, add one address per line; start the line
+# with a ^ character to designate a <a href=
+# "http://www.python.org/doc/current/lib/module-re.html" >Python regular
+# expression</a>.  When entering backslashes, do so as if you were using
+# Python raw strings (i.e. you generally just use a single backslash).
+# 
+# <p>Note that non-regexp matches are always done first.
+
+# Each list member has a moderation flag which says whether messages
+# from the list member can be posted directly to the list, or must first
+# be approved by the list moderator.  When the moderation flag is turned
+# on, list member postings must be approved first.  You, the list
+# administrator can decide whether a specific individual's postings will
+# be moderated or not.
+# 
+# When a new member is subscribed, their initial moderation flag takes
+# its value from this option.  Turn this option off to accept member
+# postings by default.  Turn this option on to, by default, moderate
+# member postings first.  You can always manually set an individual
+# member's moderation bit by using the membership management screens.
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+default_member_moderation = 0
+
+# Hold -- this holds the message for approval by the list moderators.
+# 
+# Reject -- this automatically rejects the message by sending a bounce
+# notice to the post's author.  The text of the bounce notice can be <a
+# href="?VARHELP=privacy/sender/member_moderation_notice" >configured by
+# you.
+# 
+# Discard -- this simply discards the message, with no notice sent to
+# the post's author.
+# 
+#
+# legal values are:
+#    0 = "Hold"
+#    1 = "Reject"
+#    2 = "Discard"
+member_moderation_action = 1
+
+# When a post from a non-member is received, the message's sender is
+# matched against the list of explicitly <a
+# href="?VARHELP=privacy/sender/accept_these_nonmembers" >accepted,
+# held, <a href="?VARHELP=privacy/sender/reject_these_nonmembers"
+# >rejected (bounced), and <a
+# href="?VARHELP=privacy/sender/discard_these_nonmembers" >discarded
+# addresses.  If no match is found, then this action is taken.
+#
+# legal values are:
+#    0 = "Accept"
+#    1 = "Hold"
+#    2 = "Reject"
+#    3 = "Discard"
+generic_nonmember_action = 2
+
+# Should messages from non-members, which are automatically discarded,
+# be forwarded to the list moderator?
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+forward_auto_discards = 1
+
+## Bounce options
+#
+# These policies control the automatic bounce processing system in
+# Mailman.  Here's an overview of how it works.
+# 
+# <p>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 <em>hard</em> or <em>soft</em> meaning
+# either a fatal error occurred, or a transient error occurred.  When in
+# doubt, a hard severity is used.
+# 
+# <p>If no member address can be extracted from the bounce, then the
+# bounce is usually discarded.  Otherwise, each member is assigned a
+# <em>bounce score</em> and every time we encounter a bounce from this
+# member we increment the 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.
+# 
+# <p>When a member's bounce score is greater than the <a
+# href="?VARHELP=bounce/bounce_score_threshold">bounce score
+# threshold</a>, the 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.
+# 
+# <p>You can control both the <a
+# href="?VARHELP=bounce/bounce_you_are_disabled_warnings">number of
+# reminders</a> the member will receive and the <a
+# href="?VARHELP=bounce/bounce_you_are_disabled_warnings_interval"
+# >frequency</a> with which these reminders are sent.
+# 
+# <p>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 <a
+# href="?VARHELP=bounce/bounce_info_stale_after">considered stale</a>
+# 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.
+
+# By setting this value to No, you disable all automatic bounce
+# processing for this list, however bounce messages will still be
+# discarded so that the list administrator isn't inundated with them.
+#
+# legal values are:
+#    0 = "No"
+#    1 = "Yes"
+bounce_processing = 1
+
+## Archive options
+#
+# List traffic archival policies.
+
+# Is archive file source for public or private archival?
+#
+# legal values are:
+#    0 = "public"
+#    1 = "private"
+archive_private = 1