Mailman Considered Beneficial

From 1948a22a87351b8a4c857520f22dd8558d47fdb9 Mon Sep 17 00:00:00 2001 From: <> Date: Mon, 31 Mar 2003 21:01:24 +0000 Subject: This commit was manufactured by cvs2svn to create branch 'Release_2_1-maint'. --- admin/www/jwzrebuttal.ht | 88 +++++++++++ admin/www/jwzrebuttal.html | 228 +++++++++++++++++++++++++++ admin/www/rant-links.h | 3 + misc/email-2.5.1.tar.gz | Bin 0 -> 1194675 bytes misc/sitelist.cfg | 376 +++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 695 insertions(+) create mode 100644 admin/www/jwzrebuttal.ht create mode 100644 admin/www/jwzrebuttal.html create mode 100644 admin/www/rant-links.h create mode 100644 misc/email-2.5.1.tar.gz create mode 100644 misc/sitelist.cfg 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 + +

Mailman Considered Beneficial

+ +Jamie Zawinski posted an article in 2002 titled Mailman Considered +Harmful. I know Jamie and respect him, but I respectfully +disagree with his assessment. You'd be worried if I didn't, eh? + +

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 +the +latest stable release of Mailman 2.1, unless otherwise specified. + +

Mailman is a pain in the ass for the end user.

+ +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: + +

Send a message to list-leave or list-unsubscribe and + reply to the confirmation message. It doesn't matter at all what + is in your original message. +
Mail "unsubscribe" to the list-request address and + reply to the confirmation message. +
Use a mail reader that understands the standard + RFC 2369 + List-Unsubscribe header, then just click on that header and + reply to the confirmation message. +
Visit your user's options page, 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). +

+ +What could be simpler? + +

Mailman's password mechanism provides zero security.

+ +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. + +

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 VERP-like envelopes, Mailman +can unambiguously parse any bounces from dead addresses, and can use +this information to automatically disable or delete disappeared +members. + +

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 +are useful. + +

Web-based subscriptions

+ +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 @@ + + + + + + + + + +Mailman Considered Beneficial + + + + + + + + + + + + + + + + + + + + + + + + +

+ + + +

Mailman Considered Beneficial

+ +Jamie Zawinski posted an article in 2002 titled Mailman Considered +Harmful. I know Jamie and respect him, but I respectfully +disagree with his assessment. You'd be worried if I didn't, eh? + +

Mailman is a pain in the ass for the end user.

Send a message to list-leave or list-unsubscribe and + reply to the confirmation message. It doesn't matter at all what + is in your original message. +
Mail "unsubscribe" to the list-request address and + reply to the confirmation message. +
Use a mail reader that understands the standard + RFC 2369 + List-Unsubscribe header, then just click on that header and + reply to the confirmation message. +
Visit your user's options page, 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). +

+ +What could be simpler? + +

Mailman's password mechanism provides zero security.

Web-based subscriptions

+ 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 @@ + +

Rants

Mailman Considered Beneficial 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 Binary files /dev/null and b/misc/email-2.5.1.tar.gz differ 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 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 Archival +# Options 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. +# +#

Member postings are held for moderation if their moderation +# flag is turned on. You can control whether member postings are +# moderated by default or not. +# +#

Non-member postings can be automatically accepted, +# held for +# moderation, rejected +# (bounced), or discarded, 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 general +# non-member rules. +# +#

In the text boxes below, add one address per line; start the line +# with a ^ character to designate a Python regular +# expression. When entering backslashes, do so as if you were using +# Python raw strings (i.e. you generally just use a single backslash). +# +#

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 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 accepted, +# held, rejected (bounced), and 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. +# +#

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 or soft meaning +# either a fatal error occurred, or a transient error occurred. When in +# doubt, a hard severity is used. +# +#

If no member address can be extracted from the bounce, then the +# bounce is usually discarded. Otherwise, each member is assigned a +# bounce score 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. +# +#

When a member's bounce score is greater than the bounce score +# threshold, 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. +# +#

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 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 -- cgit v1.2.3