Mailman list configuration settings

Over some years of refining listhelper and working with GNU Mailman, we've gradually learned about the effects of different mailman configuration settings. (“We” being Bob Proulx and Karl Berry.)

This list goes through the mailman list configuration pages (where we have something to say) in the order they appear in the web interface. We distinguish between those settings mandatory for listhelper to work at all, and those which are the best practices we've found and recommend.

If you have questions, suggestions, criticisms, or other comments, email us.

The most important settings

Before we get to the exegesis, a brief summary of the absolutely most important settings.

Settings strongly recommended for all lists (really, every single one):

• respond_to_post_requests = no.
• generic_nonmember_action = hold.

Settings required to use listhelper (in addition to the above):

• moderator include listhelper@nongnu.org.
• admin_immed_notify = yes.

General Options

real_name

Mailman's default is to capitalize the first letter. This usually looks weird to us, and we downcase our own lists. Of course this is just a personal preference.

owner

These addresses are listed on the public web pages for the list. If you don't want an address to be harvested by spammers, don't put it here. For lists using listhelper, we offer a generic address listhelper-moderate@nongnu.org that can be used.

moderator

These addresses are not listed publicly. The public (or not) listing is the only difference between the owner and moderator fields; they both receive exactly the same notifications from mailman. There is no reason to list the same address in both fields, though there's no harm in it, either.

Contrary to the implications of the mailman documentation for these fields, neither of these fields are relevant to who can administer/moderate the list. That is controlled solely by the password used to log in to the list's admin web interface.

listhelper lists must include listhelper@nongnu.org here (or listhelper@gnu.org, which is just an alias).

info

We recommend at least giving a url to the package home page; often that is all we put here.

subject_prefix

Some projects find it very useful to have [listname] here; others find that practice uselessly redundant. We are agnostic about it. If you do keep the prefix and you downcase the list name, you'll presumably want to downcase this prefix, too.

reply_goes_to_list

We agree with mailman's recommendation of Poster for nearly all lists, since this avoids the trap of people thinking they are replying to the sender only and broadcasting their private thoughts to the list; there is no fix for that, while the reverse problem is easily remedied by resending the msg.

Furthermore, many lists are public and can be posted to by anyone. With This list, a non-subscriber who posts is not included in replies.

The only exception to Poster that we've found is for private lists, i.e., those which are not advertised and never used by anyone not on the list. In that case, This list is reasonable and more convenient.

Some lists are technically public but rarely posted to by non-members. It is tempting to use This list for them, but in our experience this is a mistake; the chances are far too great that the replies to those seldom outside posters will not go to them and not be noticed. What's needed for such lists is an option to “reply to list and poster (if not on the list)”. The mailman maintainers rejected this idea, but a contributor wrote a patch, which unfortunately does not work in current mailman. We would welcome a fixed version.

admin_immed_notify

This must be set to Yes for listhelper lists. If a list owner finds the notifications problematic, the choices are (a) don't use listhelper; (b) don't include the list owner's address in either the owner or moderator fields; or (c) filter them out of the incoming mail, with a pattern like this:
^Subject: confirm [a-f0-9]{40}

admin_notify_mchanges

This is purely at the list owners' discretion. To minimize administrative notifications (as we usually want for our own lists), set it to No.

respond_to_post_requests

This should always be set to No, due to backscatter.

max_message_size

Mailman's default is 40, which is usually too small. For lists with many members, we sometimes set this to 100 or 400(k), to avoid huge attachments being needlessly broadcast. But usually we just use 0 and let the MTA do any size filtering.

Passwords

These passwords are the one and only determining factor of who can log in to the administrative interface (and do what). The email addresses listed in the owner and moderator fields are immaterial, as described above. This separation is a good thing, since it means people can be given admin access without also having to receive mailman notifications.

Also, there is no password recovery mechanism for administrative passwords. For lists hosted on lists.(non)gnu.org, you can ask listhelper-moderate@nongnu.org for help.

Non-digest options

msg_footer

Mailman's default is a verbose and not especially informative three-line footer. We tend to reset it to empty when we come across it; empty is now the default for lists on lists.(non)gnu.org.

Privacy options…

private_roster

For maximum protection against spammers, set this to List admin only; on lists.(non)gnu.org, the default is List members; Anyone is probably too generous in any case.

Spammers have worked out the automated mailman subscription process. We haven't seen incontrovertible evidence that they've harvested addresses by getting the list members after subscribing, but it's not unlikely. Since it is potentially useful for list members to see the subscribers, though, it is a tradeoff.

Privacy…Sender filters

This is arguably the single most important configuration page.

default_member_moderation

We've found that it's best to set this to Yes, for two reasons. First, spammers have worked out the automated mailman subscription process and then posted their junk. Second, even legitimate members sometimes set up an automated vacation reply or blast invitations to their address book that wrongly go to lists they are on, and moderating by default provides a chance to remove those posts before they reach the list. We've seen all of this.

accept_these_nonmembers

When a legitimate message is sent from a given address for the first time, we routinely approve the address for all future posts, so this field tends to grow large. It would be unbearable for every post to be delayed for human approval, so we just have to put up with the occasional spam or automated msg from such addresses (e.g., when forged).

By the way, with this and all the fields which are lists of email addresses, Mailman unfortunately accepts addresses from the ‘Tend to pending moderator requests’ page which it will later reject when the field is edited by hand: addresses with leading and trailing spaces, without an @, binary characters, and more. We sometimes just clear the field instead of trying to track down the address. It's not a bad thing if older addresses are not accepted forever, anyway.

hold_these_nonmembers

With our recommended configuration (below), there's no reason to use this field. Occasionally addresses are added to it by mistake while tending to requests. There's no harm in that, but we keep it empty when we notice.

reject_these_nonmembers

This should stay empty, to avoid backscatter.

discard_these_nonmembers

This should stay empty, to avoid accidental discards of real mail, as described below under forward_auto_discards.

generic_nonmember_action

We believe Hold is always the best setting here. Since this is such an important setting, here's a discussion of all the alternatives:

• Accept - Accepting mail from everyone is clearly a nonstarter, since then spam will just sail right through.
• Hold - We believe this is the best setting for all lists. It must be used for lists using listhelper.
• Reject - Should not be used, since it causes backscatter.
• Discard - People send real mail from multiple email addresses, while subscribing from only one. Therefore using Discard runs a significant risk of losing messages. Beyond that, this is not an effective means of controlling spam, since email addresses are arbitrary and spammers hardly ever reuse old addresses.

forward_auto_discards

This should stay set to Yes, so that real mail from addresses accidentally added to discard_these_nonmembers will be noticed.

Privacy…Recipient filters

acceptable_aliases

If the same list has a (regular) alias, it should be listed here. For example, bug-gnu-util is an alias for the bug-gnu-utils list.

max_num_recipients

Mailman's default 10 is usually fine. Occasionally there is a long thread where people do not clean up the list of recipients and it grows to more than this, causing messages to be held. In that case, there's no harm in increasing the value. Spammers rarely blast to lots of recipients in one message any more.

Privacy…Spam filters

Ironically enough, we never use this. Matching against regular expressions has proved insufficient as a general mechanism.

Bounce processing

bounce_unrecognized_goes_to_list_owner

We use Yes here, because these bounces are usually a result of mail being sent to a list member who has discontinued or changed their email address, and it's good to be able to correct that. Mailman's bounce detector is quite good in our experience, so these messages are generated only rarely.

bounce_notify_owner_on_disable

To minimize administrative email, we use No. Generally, we don't feel the need to keep tabs on (un)subscriptions, so if a subscriber's email has stopped working, we're not going to do anything about it anyway. Thus, if you set admin_notify_mchanges to Yes, it would make sense to set this to Yes too, and probably not otherwise.

bounce_notify_owner_on_removal

Same as previous item.

---

General Options - Passwords - Non-digest options - Privacy options - Privacy…Sender - Privacy…Recipient - Privacy…Spam - Bounce processing - Archiving options - Content filtering - Tend to pending requests

Archiving options

We recommend leaving archiving enabled. On the few occasions when we've disabled it, we always found, sooner or later, that we wished we had the archive.

archive_volume_frequency

Traffic permitting, consider reducing the frequency to Quarterly or even Yearly from the default of Monthly. Mailing lists often live on for many years, and the list of months on the archive page can get long and painful to peruse in itself.

Content filtering

Here we recommend not enabling content filtering. It is too unreliable to guess what legitimate/spam messages might/might not include. Better to leave it to other levels of mail delivery.

Tend to pending moderator requests

Our process here:

• For real messages, of course accept them, and enable the address for future postings: clear the moderation bit or add to the sender filter Accepts, as needed.
• For spam, just discard with no further actions.
• For the occasional real message which needs to be redirected to be edited (e.g., an excessively huge attachment), we usually reject it from the “View all messages” link, with a customized ( message including our name.
• For the occasional real message that needs to be redirected to another list (e.g., it was sent to an announcement-only list), we either reject it as in the previous item, or do it ourselves by forwarding it to our own mailbox and then resending it, depending on how much trouble we want to take.

Backscatter

“Backscatter” is one common name for what happens when a spammer forges a sender address and a mail server bounces the mail back to that (real) address. Example: spammer sends junk mail to a bogus address, with a From: address of karl@gnu.org. Result: karl receives the bounce, including the original spam message, as if he had actually sent it.

In general, this can happen with any kind of automated reply, such as vacation messages. Therefore we recommend (with regret) against ever using such things. For mailman, this means setting respond_to_post_requests to No, keeping reject_these_nonmembers empty, and never using Reject for generic_nonmember_action.

For a more comprehensive discussion, see the Wikipedia entry on backscatter.

(See intro for general comments and contact address.)