Philip Jacob

Love/Hate/qmail

· Philip Jacob

I’ve been a qmail convert since I worked for pate in 1999 when it truly was the best option out there insofar as MTAs were concerned. Maybe it still is. I wish the licensing terms were compatible with the terms that my preferred distribution for Linux-based servers uses.

Qmail, for those of you who don’t know, is a mail server. It receives emails, usually from the network, and processes them by delivering them locally or passing them on to their ultimate destination on a remote host. It’s fast, secure and very stable. Almost no maintenance is required.

These days, however, you need more than just something to process mail: you usually need a virus scanner, anti-spam facilities, some kind of user database that doesn’t require system accounts, integration with IMAP and POP3 servers, support for mailing lists, TLS, SMTP-Auth, and flexibility at every corner for your own customizations.

But it strikes me that at the end of 2004, these needs ought to be commoditized such that a reasonably competent sysadmin can simply install all of the above using their distribution’s package manager. This shouldn’t be hard.

Instead, due to the Qmail license, the process requires a certain level of expertise, patience and time. Download qmail, vpopmail, courier, the netqmail patches, vqadmin, qmailadmin, qmail-scanner, ClamAV, and SpamAssassin. Verify compatibility between all of the above, usually by reading the notes buried in qmail source patches, docs and mailing lists for all of the above. Oh, and qmail.org is probably one of the most user-unfriendly websites in the world. They claim:

It’s not designed to be easy to use – it’s designed to be comprehensive.

… as if the two were mutually exclusive.

By any measure, the complexity and effort involved is a pain in the neck. And I don’t believe that it provides any real benefit over simply installing prebuilt binary packages.

Your other option is to go and find prebuilt packages made by someone who is in the position you are in. I’ve been down that road before and had to abandon that approach when I needed some kind of special patch to the qmail source.

I have to give a special nod to the traditional UNIX mentality here: do one thing and do it well. That’s what all of the aforementioned packages do. They each represent a best-in-class solution to a specific problem. Integrating them is the trick. It certainly is possible, but it seems like it could be a whole lot easier. I like modularity and loose coupling, but I wish the pieces fit together a little easier. One thing that would help in this regard is license-compatibility. If the qmail license was a traditional open-source licence, someone could customize it to integrate with various sundry components and turn out a click-and-run email server.

In spite of all the trouble that one must endure while putting together a setup like this, once it is running, it tends to stay running without intervention. If there is another integrated open-source stack that people use for email, I haven’t found it yet.