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.

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

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

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.

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; this is the default for all lists.
The setting Anyone is surely 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. 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.

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.

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
MailNews 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_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.

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

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.