Mailman list configuration settings

Over several 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 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. For plenty of the settings we have nothing to add to the mailman description, and so those are omitted here.

For mailman administrators looking for scripts to help with general tasks, we recommend Mark Sapiro's page; full of good stuff. (By the way, although the scripts say they have to be installed in the mailman bin directory, in our experience it suffices to set PYTHONPATH.)

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 most important settings.

Settings strongly recommended for all lists (yes, 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. 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 or listhelper@gnu.org here.

info

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

subject_prefix

If 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 automatically 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 often 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

We recommend making this empty, which is the default for lists.(non)gnu.org. Mailman's default is a verbose and not especially informative three-line footer.

Privacy options…

private_roster

For protection against spammers, set this to List admin only; this is the default for all lists. The setting Anyone is certainly 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 almost certain. Although it is potentially useful for list members to see the subscribers, it does not seem worth the risk of harvesting.

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.

dmarc_moderation_action

We recommend setting this to Munge From (the default for lists.(non)gnu.org), to appease DMARC. It is the best available way to minimize mail failures and unsubscriptions.

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 would 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

header_filter_rules

Some GNU mailing lists are still connected to Usenet groups, such as help-gnu-emacs (gnu.emacs.help) and bug-gnu-utils (gnu.utils.bug). Lists with an associated Usenet group have the mailman attribute linked_newsgroup set.

By default, mailman passes through all newsgroup posts to the mailing list, without all the normal filtering. The settings in the Mail<->News gateways section do not help. What does help is a one-line change to Moderate.py, which makes newsgroup posts have the same moderation as normal posts.

(Historical: before we got that assistance, we set Spam Filter Regexp to the value Newsgroups:, with Action=Hold. This has the undesirable side effect of forcing manual approval of every real message posted to the newsgroup and then gatewayed to the mailing list, even if the sender address is already approved. But letting spam through at will seemed worse.)

Bounce processing

bounce_processing

Usually Yes is highly desirable (and is the default), but in the case of small private lists where all members are known, you may want to consider No, to avoid accidental unsubscription.

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.

In addition to the options here, if you have access to the system, we suggest adding a simple archive to each LIST-bounces address. It is common for users to wonder why they were bounces. mailman swallows bounces after processing, and so there is no good record of what happened without an independent archive. For example:

mm-bounces: /home/mailman/bounces/archive
...
list1-bounces: "|/usr/lib/mailman/mail/mailman bounces list1",mm-bounces
...
list2-bounces: "|/usr/lib/mailman/mail/mailman bounces list2",mm-bounces
...

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.

Content filtering

We recommend not enabling content filtering, that is, leaving filter_content=No. It is too unreliable to guess what legitimate/spam messages might/might not include. Better to leave it to other levels of mail delivery.

On the other hand, you may want to enable convert_html_to_plaintext, especially if a given list regularly receives HTML-only messages. Messages more typically have both HTML and plain text parts, but there are no rules.

For this, you'll need to set filter_content=Yes. In this case, we strongly recommend clearing all the other values, most importantly pass_mime_types and filter_filename_extensions (which have non-empty defaults). Otherwise, mailman could unexpectedly remove useful attachments and/or discard messages.

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.
• Occasionally, a real message from a member will not have any option to unmoderate. This usually happens when the sender is subscribed to the list under another address, which is moderated, and the message headers are unusually crafted; the most common case is people reading lists through gmane. The answer is to look in the headers for the gmane or whatever other addresses the sender is using, and unmoderate whatever is subscribed.
• For spam, just discard with no further action.
• 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 handwritten note, including our email address so the sender can correspond.
• 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 at top for general comments and contact address.)