Thus spake Sam Varshavchik on Tue, Dec 21, 2004 at 08:41:56PM CST

Looks like they're running 2.0.9 for some reason. I'm running 2.1.4 and Mailman stable is at 2.1.5, I believe. In these versions, all choices on what to do with email include 3 or 4 options. Accept (if appropriate), hold, reject and discard. Hold sends an approval req. to the list moderator, reject discards the message and sends a list DSN to the sender, discard just deep-sixes the message without notifying anyone.

The problem you cite was obviously of concern to the developers since it was addressed in later versions. I'd guess that there may be some compatibility issues between 2.0.9 and 2.1.x and SF hosts so many lists that the inconvenience of breaking them all and having to fix them outweighs the inconvenience of having to deal with cruft issues of not auto-deleting stuff.

For a new installation, however, Mailman shouldn't have this problem. I've been fairly well pleased with it, having previously used ezmlm which I hacked to be properly compatible with courier (patches, documentation available on request). There were so many little details of my courier/qmail/ezmlm setup that had to be dickered with to set up a list that I seldom got a list to work right after the initial setup, and had to dicker with the details a few times to get it to work. With Mailman, on the other hand, things just work. One CLI command sets the list up, and I can go to the web UI and tweak preferences. I've got a courier-to-mailman.py program (available on request) which handles all the various lists and list addresses for an account out of a single .courier-default file.

Mailman tends to be pretty chatty, compared to other list servers I've used, and it's probably not as fast as my ezmlm/courier/qmail combo list server, but everyone who uses the lists seems to like it just fine, and they don't have to bug me take care of list administration jobs for them :-)