diff options
| -rw-r--r-- | admin/www/jwzrebuttal.ht | 88 | ||||
| -rw-r--r-- | admin/www/jwzrebuttal.html | 228 | ||||
| -rw-r--r-- | admin/www/rant-links.h | 3 | ||||
| -rw-r--r-- | misc/email-2.5.1.tar.gz | bin | 0 -> 1194675 bytes | |||
| -rw-r--r-- | misc/sitelist.cfg | 376 |
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"> </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"> +<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"> +<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"> + +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="http://www.python.org/"><img border=0 + src="./images/PythonPoweredSmall.png" + ></a> <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"> + +</td></tr> +<tr><td bgcolor="#eecfa1"> +© 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"> </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 Binary files differnew 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 |