Entries tagged skxlist

Related tags: skxmail.

Humans don't drink blood.

Saturday, 16 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



Recent Posts

Recent Tags