Skip to content

Humans don't drink blood.

16th May 2009

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

  1. [gravitar] Andreas Metzler Submitted at 16:59:24 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

  2. [author] Steve Kemp Submitted at 17:12:34 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.

  3. [gravitar] Simon Huggins Submitted at 07:44:35 on 17 May 2009
    Apart from NIH, what was wrong with enemies-of-carlotta out of interest?
  4. [author] Steve Kemp Submitted at 15:31:32 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.

  5. [gravitar] Tobias Submitted at 20:50:32 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...
  6. [author] Steve Kemp Submitted at 21:26:42 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.)