Introduction
I'm trawling through the mailman web interface, trying to make sure I have things set up as privately as possible. I did this already, but either I missed some, or some settings got un-set in the last migration. I wish there was a page in the mailman interface that gathered these settings together in one spot. Possibly with a meta-button to select different privacy profiles with appropriate default settings. I mentioned this on #mailman, and somebody suggested I make a wiki page.
Step one, use the shell command "list_lists" to make sure you know all of the lists on your box, including the ones that aren't advertised.
$ sudo list_lists
Step two, remove any lists that you don't need anymore.
Emergency Moderation
If you're not sure you want to remove the list, then instead turn on Emergency Moderation. If you enable Emergency Moderation, you'll be emailed a request to approve any post going out on this list.
Go to the mailman admin web interface for the list.
Go to the "General Options" page.
Scroll down to the last section, "Additional Settings".
The first setting in the section should be "Emergency moderation of all list traffic."
Click "Yes" and then scroll down to the bottom and click the "Submit Your Changes" button to enable Emergency Moderation.
Archiving and removing the list.
If you're sure you want to remove the list, but you're paranoid like me, first use "list_members" to back up the list's subscribers, and config_list to back up the list settings.
You also might want to make a backup copy of the list archives. This depends on your particular distribution's installation of mailman, but usually they're under the mailman directory, e.g. in debian it's /var/lib/mailman/archives/private/yourlistname. Note that the actual archive files are always under mailman/archives/private. The /mailman/archives/public directory only contains links to the files in the mailman/archives/private directory.
Finally, use "rm_list" to remove the list.
$ sudo config_list -o testlist_settings.out testlist $ sudo list_members testlist > testlist_members.out $ sudo tar -cf testlist_archives.tar /var/lib/mailman/archives/private/testlist $ sudo rm_list testlist
Step three, go through the lists in list_lists and use the web interface to make them as private as possible.
You can also use config_list to set the settings, but I just learned about config_list, so I'll have to write that up at some later date.
The following are the settings I'm choosing to use. Most of my lists are pretty private, and fairly small, on the order of 50 or less list members, usually a previously geographically colocated community who are just keeping in touch with each other. I'm not going to debate the merits of each setting, but I will try to explain why I chose it.
Generally speaking, I have two kinds of lists, community lists, where everybody can post, and announcement lists, for some small organizations. There are a few minor differences in privacy settings between the two. For example, announcement lists have "Who can view subscription list" set to "list admin only." I'll try to note any differences below.
As I'm going through the settings, I've also created a test list to look at the defaults. It appears that Mailman's default settings are fairly good (at least for my preferences). The two big items are requiring "Confirm and Approve" for subscription, and making new list members moderated by default.
Summary
I'll discuss the changes in detail below, but here's a quick checklist of the settings I make sure to change. I'm leaving out the settings that are important, but have safe default values. I'll mention those below, in the detailed discussion. For now, the checklist:
General Options
"Should administrator get notices of subscribes and unsubscribes?" Yes.
Privacy Options, Subscription Rules
"Advertise this list when people ask what lists are on this machine?" No. "What steps are required for subscription?" Confirm and Approve "Who can view subscription list?" List members (the default) for community lists "Who can view subscription list?" List admin only for announcement lists
Privacy Options, Sender Filters
"By default, should new list member postings be moderated?" Yes. "Action to take for postings from non-members for which no explicit action is defined." Discard. "Should messages from non-members, which are automatically discarded, be forwarded to the list moderator?" No.
Privacy Options, Recipient Filters
"Ceiling on acceptable number of recipients for a posting." 4
Archiving Options
"Is archive file source for public or private archival?" Private
Detailed Discussion
General Options page
"Hide the sender of a message, replacing it with the list address (Removes From, Sender and Reply-To fields)"
I leave this setting on the default setting, No. Mostly I'm not that worried about my list members doing something evil. The list archive will be private too, so turning this on will probably cause more confusion than it's worth.
"Should administrator get notices of subscribes and unsubscribes?"
I usually set this to Yes, but then, as I said, my lists are small and generally an unsubscribe or subscribe is somewhat rare. We're going to be requiring approval of subscriptions anyway, this just lets me notice when a list member unsubscribes.
"Maximum length in kilobytes (KB) of a message body."
I generally leave this at the default setting of 40 kilobytes. This isn't a privacy setting per se, but limiting the message size does help to cut down on both spam and viruses, because normal list traffic just isn't that big, very often.
Privacy Options..., Subscription Rules page
"Advertise this list when people ask what lists are on this machine?"
I set this to No, to make it just that little bit harder for spammers looking to harvest email addresses from the lists. I don't know that this actually slows them down at all, but it just seems like a good idea to me.
Also, most users seem to find the mailman list signup page too confusing, so I usually put up a custom home page for the list and send out that URL, which makes the list advertisement less crucial.
"What steps are required for subscription?"
The default is Confirm, but I always select Confirm and Approve. Again, my lists are low traffic enough that I don't have a problem handling these requests.
Sadly, given the state of spam on the internet today, I think it's about impossible to run a decent mailing list without Confirm and Approve. If you're running a lot of lists, or large lists, you'll have to get some volunteers from the list to help with this.
It'd be nice if you could farm out specific responsibilities for mailman, for example having list registrars, list admins who only handle subscription requests and don't have access to the rest of the administrative powers. Or list members who review posts and approve them (for new users, until they've posted enough that you can trust them).
"Is the list moderator's approval required for unsubscription requests?"
I leave this on the default setting of No. I've never had a problem with virus spam or anything else causing false unsubscribe requests, and the possibility of a user being unable to unsubscribe while being spammed by my lists makes my skin crawl.
"List of addresses which are banned from membership in this mailing list."
The number of spammers on the internet is infinite, so I don't generally use this setting. However, if you get a persistent bot trying to subscribe from the same address, this may be useful to protect yourself (and your other admins) from a flood of approval requests.
Also see Privacy Options..., Sender Filters page, "List of non-member addresses whose postings will be automatically discarded." Theoretically, they should never get a chance to post at all, but defense in depth is a security fundamental.
"Who can view subscription list?"
Never "Anyone". Usually I use List members for community lists, and List admin only for announcement lists.
"Show member addresses so they're not directly recognizable as email addresses?"
I leave this on the default setting of Yes. I'm also going to lock down the archives so they can only be viewed by list members, but it's good to have defense in depth.
Privacy Options..., Sender Filters page
"By default, should new list member postings be moderated?"
On a highly public list, Yes. My lists are small enough that I usually know who the new list member is, so I don't use it that often myself.
But it's common on the more public lists. This means you have to have enough list admins to review and approve the first few posts from list members, to make sure they aren't spammers. Once they've shown themselves to be real human beings, look the user up on the Membership Management page and uncheck the "Mod" column.
"Action to take when a moderated member posts to the list."
Keep the default setting of Hold.
"List of non-member addresses whose postings should be automatically accepted."
This is useful when occasionally you have a user who posts from an odd MTA that mangles his or her address. A large university near here has such a system, it appends a "+" to the email address. The hapless users who work or attend there can't post to the list unless I add their mangled address to this setting.
"List of non-member addresses whose postings will be automatically discarded."
See "List of addresses which are banned from membership in this mailing list", above.
"Action to take for postings from non-members for which no explicit action is defined."
Set to Discard, sadly, which isn't the right thing to do, but causes the least harm.
This defaults to "Hold", which will quickly fill up your mailman admin request queue.
It should be reasonable to set it to "Reject", but these days spammers use fake reply-to headers and usually set them to somebody they don't like. If you send a reject message, then you're volunteering to help spammers DDOS somebody (google on "joe job").
"Should messages from non-members, which are automatically discarded, be forwarded to the list moderator?"
Set this to No. I used to have this set to "Yes.", but frankly I got so many forwards, even from my tiny lists, that I ultimately ended up just tagging and archiving them all.
I really, really don't like this, no more than I like discarding instead of rejecting. It pretty much rules out any way to sort out problems through normal channels. Instead, a list member has to figure out that their messages aren't getting out and contact a list admin directly, instead of using the great support Mailman has for this sort of thing. But there doesn't seem to be a reasonable alternative.
Privacy Options..., Recipient Filters page
"Ceiling on acceptable number of recipients for a posting."
I usually crank this down to 4, instead of the default 10. Long CC lists are a classic mark spam sign, but even regular users can have a tendency to abuse them. Remember the old days, when everyone understood that "spam" wasn't just commercial, but was about consent?
This sometimes generates administrative headaches, when users get torqued off that they have to send an individual post to the list for it to get through. But I feel it's worth the headaches.
Privacy Options..., Spam Filters page
I don't usually mess with these settings at all.
I do use some MTA settings that rely on Relay BLock Lists to block out known spam IP addresses at the MTA level, and also some settings to block messages that show well-known clues that they're from spammers (http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt).
I'm a big believer in keeping the channels of communication open, so having to do this grates on my nerves. But you just can't get anything done with the amount of spam on the internet.
Archiving Options page
"Is archive file source for public or private archival?"
This defaults to Public. I don't run any highly public lists; most of my lists are relatively small communities, so I set this to Private. If I ran a list for discussion of software development, for example, I would probably leave this public, and count on the automagic mangling of email addresses that Mailman provides.
Content Filtering page
I don't generally have to set this, because the message size limit catches any problem messages first. Maybe it's old-fashioned of me, but I hate gratuitous email binaries. If there's some legitimate content, then I extract it, put it on the web site, and post an announcement, so people who want it can either fetch it, or request it.
Again, with a larger, more public list you probably want to take advantage of this page.