The foulest stench is in the air

Saturday, 5 August 2006

I received a few interesting comments on my last post about mailing list software so I’m going to summerise my current thoughts.

Before covering the available software I’ll say what I personally need from a mailing list manager:

  • The ability to run multiple lists on a single host.
  • The ability to use virtual hosts, such that list-foo@one.com is distinct from list-foo@two.com.
  • The ability to create different types of lists:
    • Open list – anybody can post a message which gets sent to all subscribers.
    • Closed list – Only list members may post
    • Admin-list – Anybody may join, but only “special” users may post.

When it comes to the handling of spam I mostly don’t care. Messages are filtered via the mailserver at SMTP time (ditto for viruses) and although moderation is generally useful I prefer to either bounce or eat the messages which are not forwarded. (Either case is fine so long as logs are available). This simplifies things significantly since the pedning messages don’t need to be stored/queued.

Here is a list of all the mailing list software which is available to users of Debian’s Sarge release along with some of my thoughts/comments/impressions. (Some of these details may be wrong, I’d happily be educated …):

ecartis

The Ecartis package for Debian GNU/Linux is mostly broken. In sid the package is essentially unmaintained, and that is a worrying sign.

Ignoring that for the moment the software works reasonably well. It allows most of the kind of control I desire but the significant downside is that it is severaly broken with regard to character sets and encoding issues.

For a cromulent example see this message.

enemies-of-carlotta

This software wins double-plus bonus points for a most excellent name. Naming software is hard, and although the relationship between the film and the purpose of the software is random I like it!

eoc suffers from a virtually non-existant set of documentation. Whilst it might be simple to use I it isn’t documented except in a single manpage. I seem to recall I had difficulty getting my Exim4 configuration to pass relevent environment variables ($SENDER + $RECIPIENT) passed into the script properly. The lack of documentation just made this more irritating.

fml

There is a lot of documentation for this, which is half in English and half in Japanese.

I admit I mostly didn’t explore this software – although my impression is that it doesn’t have support for virtual hosts.

mailman

Mailman is big, popular, and I dislike it with a passion.

The admin interface has a billion configuration options, but even if you know they exist finding the damn things are an impossible job.

The system requires about five python processes running even when it is “idle”. In my mind a mailing list software doesn’t need a daemon componant – just a program to spawn when a message “comes in”. The whole password system is broken and gains you zero additional security.

Again to rail against mailman: it has integrated message archival, something i think should be distinct. (eg. mhonarc).

Virtual hosting is possible, but I believe that mailing list names must be distinct regardless of domain name. That may not be correct honestly I’ve detested the softwware with a passion which suprises me and I may not be 100% objective here.

mlmmj

Looks nice. Looks clean. doesn’t look particularly joyful. (The name mlmmj means “mailing list managing made joyful”.)

It doesn’t appear to support virtual hosting, and it doesn’t appear to support enough different list types.

quickml

Listens upon a network port (10025 by default) and not support different list types or virtual hosting.

smartlist

Complex. Icky.

sympa

Seems very featureful, but it is yet another system which has an integrated web-component like mailman == bad.

It doesn’t support having the same named mailing list in multiple virtual hosts, although it appears to do everything else I desire.

In summery: There are several available packages, but none are good, and many are actively bad.

I still believe that creating another list server would be a useful thing to do. I’ve written a brief design overview elsewhere which I will post for comment later.

I’d like to support a couple of “advanced” features such as allowing the mailing list software to only accept GPG signed messages, or to act as a remailer such that messages posted to the list will be automatically GPG signed prior to delivery to all users.

Looking around I think most of the individual bits of code are available (in Perl). eg. Mail::Message, Mail::GPG, etc. Its just a matter of gluing the bits together in a modular fashion.

| No comments

 

 

Recent Posts

Recent Tags