Wed, 15 Feb 2006
Why Qmail should not be used
In the local Linux mailing list somebody asked which software should he choose for the mail server. I wrote a lengthy followup on why should not Qmail be used as a MTA for new installations. I think it is a good idea to rephrase this here. This comes from a person who maintains several Qmail instalations, including the linux.cz listserver. This is not result of a short-time anger with Qmail, but rather a thought-out opinion, formed over years of Qmail usage.
Firstly, some advantages which Qmail have:
- Easy to maintain (even though it is quite different from other MTAs).
- Fast.
- Stable (which is an euphemism to "not developed anymore" :-)
- Quite secure, written by a security expert.
- Easy to write extensions for. qmail-local extracts the usually-required data from the message to the environment variables, so local delivery and filtering scripts do not need to do the hard and error-prone work.
And now the shortcomings of Qmail:
- The lack of a standard configuration procedure (i.e. GNU autotools or something similar). The author is not a good software engineer in terms that he likes to do everything himself, not using system libraries, etc. This leads to portability problems (as the h_errno problem Qmail has with newer Glibcs.
- Qmail is not Open Source. While it is free enough, the license does not allow distributing modified binaries, so that it cannot be shipped with any Linux distribution. This leads to lack of users, and slower development. Also it is not possible to distribute binaries to (for example) your customers.
- The source code is a mess (see, for example, how many times the number "100" is hard-coded in the source code).
- For long-term installations (such as linux.cz) there is a problem with the format of the queue - Qmail identifies the messages by numbers, which are taken from the inode numbers of the files themselves. So it is hard to move the queue to another volume (e.g. during the HW upgrade).
- The queue structure is relatively complicated. Tasks like "remove all of the 15_000 mails looping between a@b.cz and c@d.cz from the queue" are hard.
- Even though some things are configurable, many have a hard-coded upper limit - e.g. the maximum number of outgoing SMTP sessions: this means that after restarting Qmail, it does hardly any delivery for hours, because all remote SMTP sessions are used for retrying the old messages in the queue, which will time out anyway.
- It cannot do IPv6 (well, there are third-party patches, but they are far from complete).
- qmail-smtpd has almost no configurability, which in the present world full of spam and viruses means, that for example mails to non-existent users are accepted to the incoming queue (and the SMTP session is closed), and only then the attempt to deliver this message is made. This means that when the user does not exist, Qmail has to report the bounce to the envelope sender address, which is usually forged. So the innocent people are receiving these bounces. The correct way should be to refuse the message inside the SMTP session, without generating the bounce. Sending the false bounces can earn a well-deserved presence on the SpamCop blacklist (not to meniton that sending a random garbage to the innocent users is bad).
The latest problem is the worst one, because it is a design problem - it is a shortcoming of Qmail's modularity. It cannot be solved without rewriting qmail-smtpd (but that would require that it can access the database of users/aliases/etc., so it would have to leave its chroot jail).
So my recommendation is: do not use qmail for new installations. Choose Postfix or something like that instead.