Mailman Considered Beneficial

Overview

Home

Security

Features

Donate! (exit)

More Information

Wiki (exit)

Discussion Lists

Launchpad Project Page

Rants, Papers, and Logos

Bugs and Patches

Mirrors

Rants

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?

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