Mailman Considered Harmful
© 2002 Jamie Zawinski <jwz@jwz.org>

Mailman is very popular mailing list manager software. Because it's popular, I end up having to use it a lot, as it tends to drive mailing lists I'm interested in. It's a huge pain in the ass to use, and has a braindead security model. Here's a rant about it. I keep hoping that maybe someday the clue-elves will arrive in the night and sort this out, but it's been years, and it hasn't happened yet. (And yes, I've sent these complaints to the developers too. I'm still waiting for the elves.)

1. Mailman is a pain in the ass for the end user.

Compare and contrast this sequence of actions:

With sane mailing list software:

• Mail "unsubscribe" to "foo-request".
• Get "please confirm" mail back.
• Reply.
• Done.

With Mailman:

• Mail "unsubscribe" to "foo-request".
• Get "I don't understand that" mail back.
• Find the admin URL in that web page.
• Load the web page.
• Try to log in.
• Realize you don't remember the password that Mailman generated for you when you subscribed, because you haven't ever used it even once.
• Find the "mail me my password" button.
• Wait for the password to arrive.
• Go back to the web page.
• Try to log in.
• Waste some more time trying before you realize it doesn't work without cookies.
• Turn cookies back on.
• Log in.
• Find the unsubscribe link.
• Done.

Now which was easier? What benefit am I getting from Mailman's convoluted method, exactly?

2. Mailman's password mechanism provides zero security.

It does, however, do two things: cause inconvenience, and suggest to users who might not know better that mailing passwords in email is ever a good idea.

Mailman requires you to enter a password on its web page to do anything.

The password is pointless.

It provides no more protection than the "reply to this message to be subscribed" mechanism. As you can tell the web page to mail you a plain-text password, the only real validation that is going on is that the person issuing the subscribe request is a person capable of reading mail sent to the address they are subscribing.

It's important that mailing list software do this check, to avoid prank subscriptions. But the "reply to this" method is N less steps than the password-I-don't-know-I-have method, while being absolutely equivalent from a security point of view.

So the password thing is merely irritating and a waste of time: it has no benefits.

Plus, as I said, it will encourage poor password management among naive users. In the real world, most people tend to use the same password for everything. They shouldn't, but they do. So now, users will be typing their (secure, important) login passwords into Mailman's password prompt -- but Mailman explicitly does not manage passwords securely! So now the user has inadvertently exposed a secure password by letting it pass through an insecure site. And once a month, it will be exposed again, as Mailman sends out its you-are-still-subscribed "reminder" messages. You can argue that this is the user's fault, but I argue that good software does not encourage naive users to do stupid things.

Just say no to Mailman!

I use Smartlist (which comes with Procmail) to manage all of the mailing lists that I run. Smartlist is a huge pain in the ass to configure, but after it's installed, it works very sensibly. In particular, it does the "reply to this to confirm" trick completely painlessly from the end user's point of view: all they have to do it hit "reply" to confirm their subscriptions, and they're done.

And it's trivially easy to set up web-based subscription mechanism for Smartlist-based lists, as I did for the DNA Lounge announcements mailing list: this is just a simple CGI that does some basic syntax-checking on the entered address, and then sends mail to the -subscribe address with that address in the From: line. Then the user simply hits reply once they get the subscription-confirmation mail.

In fact, there's nothing Smartlist-specific about that: the CGI just sends mail, it doesn't care what software is on the other end.