Humans don't drink blood.

16 May 2009 21:50

I've said it multiple times, but all mailing list managers suck. Especially mailman. (On that topic SELinux is nasty, Emacs is the one true editor, and people who wear furry boots are silly.)

Having setup some new domains I needed a mailing list manager, and had to re-evaluate the available options. Mostly I want something nice and simple, that doesn't mess around with character sets, that requires no fancy deamons, and has no built in archiving solution.

Really all we need is three basic operations:

Confirmed opt-in subscription.
Confirmed opt-out unsubscription.
Post to list.

Using pipes we can easily arrange for a script to be invoked for different options:

# Aliases for 'list-blah' mailing list.
#
^list-blah-subscribe$:   "|/sbin/skxlist --list=list-blah --domain=example.com --subscribe"
^list-blah-unsubscribe$: "|/sbin/skxlist --list=list-blah --domain=example.com --unsubscribe"
^list-blah$:             "|/sbin/skxlist --list=list-blah --domain=example.com --post"

The only remaining concerns are security related. The most obvious concern is that the script named will be launched by the mailserver user (Debian-exim in my case). That suggests that any files it creates (such as a list of email addresses - i.e. list members) will be owned by that user.

That can be avoided with setuid-fu and having the mailing list manager be compiled. But compiled code? When there are so many lovely Perl modules out there? No chance!

In conclusion, if you're happy for the exim user to own and be able to read the list data then you can use skxlist.

It is in live use, allows open lists, member-only lists, and admin-only lists. It will archive messages in a maildir, but they are ignored for you to use if you see fit.

List options are pretty minimal, but I do a fair amount of sanity checking and I see no weaknesses except for the use of the Debian-exim UID.

ObFilm: Blade

Tags: skxlist, skxmail | 6 comments

Comments on this entry

Andreas Metzler at 16:59 on 16 May 2009

You write:

The most obvious concern is that the script named will be launched by the mailserver user (Debian-exim in my case).
That suggests that any files it creates (such as a list of email addresses - i.e. list members) will be owned by that user.

That is no-concern, since exim can run deliveries as an arbitrary dedicated user. Normal mailman installations on exim make use of this feature, too.
cu andreas

Steve Kemp at 17:12 on 16 May 2009

Thanks for that reminder, Andreas. I guess I should have remembered that from installing mailman in the past.

This time round I just added the aliases to my virtual hosting transports and didn't configure any user/groups. So it was running as Debian-exim by default and I figured I'd leave it like that with only a warning.

Simon Huggins at 07:44 on 17 May 2009

Apart from NIH, what was wrong with enemies-of-carlotta out of interest?

Steve Kemp at 15:31 on 17 May 2009

The last time I examined mailing list managers Enemies of Carlotta suffered from a distinct lack of documentation.

Having just downloaded the package in Sid that still seems to be the case, sadly.

Tobias at 20:50 on 17 May 2009

I would suggest couriermlm (Debian package courier-mlm), but sadly it pulls in quite a lot of courier, which might not be desirable if you don't use courier as you mail server. The documentation (http://www.courier-mta.org/couriermlm.html) only handles the case where you use it with courier, but using it with another mail server seems to be possible. You just have to set the DEFAULT environment variable for the control commands...

Steve Kemp at 21:26 on 17 May 2009

Thanks for the pointer Tobias, I'd not heard of that one before.

(Although I do tend to use exim4/qpsmtpd for my mail-handling needs so it isn't a perfect fit.)

Humans don't drink blood.

Comments on this entry

Recent Posts