mn :: comp :: net

Unix Mail Intro

In case you didn't know, Sendmail is not the only (or best) game in town when it comes to Unix mail. Anybody who's perused Freshmeat and looked at the 26 text editors probably doesn't find it surprising that there is choice. Thanks to JC Lawrence and Terje Elde and the rest of the Yashy-Hack list for extra input here. If you're just looking for a recommendation, Postfix is in my opinion the best choice for ease of configuration, license, and performance.

Here are the majors:

Sendmail -- older than dirt, and the preferred solution for "corporate" usage. Sendmail has been the vector for quite a lot of worms, remote root, and local root compromises. This comes with the territory when you run a network-accessible program with SUID privileges. Sendmail is also relatively slow, as it can only process one transaction at a time. Faster variants are available for money. Current version is 8.11.3, see Sendmail.com and Sendmail.org. There haven't been any remote root compromises since a major security audit about three years ago, but Sendmail's detractors will say it's still only a matter of time; the architecture of a single program with root privileges and network access is fundamentally flawed. All of the other choices use different programs with different privilege levels for different purposes.

The thing about Sendmail is, it has a truly awful configuration file. There's no making sense of it for normal people, so there are a number of GUI auto- configgers which propose to fix up the configuration file for you. Good that it's point-n-click I suppose, if you like that sort of thing -- hence, the corporate mail. I've been burned by going that direction, though, and cannot recommend using Linuxconf or Webmin or their ilk unless you've got the time to go repair the occassional mistake.

Qmail -- Dan Bernstein's MTA was designed from scratch to be fast and secure. However, it doesn't play nicely for sendmail-trained administrators, because it does basic things like delivering email for local users in radically different ways. Probably the biggest difference is that qmail writes mail one-file-per-message into a Maildir in the users' home directory (e.g. /home/jack/Mail/) instead of one-file-per-mailbox in a central location (e.g. /var/spool/mail/jack). Qmail is not GPL but is free to download, compile, and use -- you may not make changes to the core software but you may provide and maintain your own patches. Current version is 1.03, see qmail.org and cr.yp.to/qmail.html. Qmail inspires love or hate; it doesn't follow RFCs in the interest of performance and has been known to crash other sites' Sendmail installations. There are some interoperability issues with other mail software, it isn't FHS-compliant, and the license strikes many as ambiguous.

Postfix -- best of both worlds, IMHO. Weitse Venema's MTA was designed as a drop-in replacement for sendmail. Like qmail it runs as a system account with limited permissions, and is so fast that the limiting factor on a mail relay is usually hard disk I/O. Postfix can work with mbox or Maildir, doesn't require any changes to external programs like Mailman or majordomo, and is released under an extremely BSD-like "IBM Secure Mailer License." Current version is release-20010228, see Postfix.org.

Exim -- JC Lawrence says: Finally you fail to mention Philip Hazel's Exim, which, while a monolithic design, significant challenges Sendmail for configurability (and significantly exceeds it in several categories). Of all the common MTAs Exim has the best written and most clearly stated and hinted documentation. Exim has perhaps the most human readable config file (I've gone back to read Exim configs I wrote 3 years ago and found them trivially understandable). The performance curves for Exim are smoother, especially in terms of host load and attack rate than either QMail or Postfix, with very similar values in testing here for the inflection points of constantly busy and queue saturation, and it pays much more (any) attention to historical MX delivery hinting than any of the other MTAs which make it particularly suitable for large-population of slow MXes.

Performance: Mail servers operate with each other on a public network with unpredictable performance characteristics, delivering a product that can supposedly sustain some delay (though more time-sensitive information is being emailed all the time, such as urgent monitoring system alerts). Chances are good that any modern server will be able to handle the workload. That said, a mail server will hit a performance inflection point when the incoming mail is piling up faster than the outbound queue can be processed. If you want to look at how a MTA performs, look at how quickly it can dispatch its queue and how that speed is affected by other things (like enqueuing new incoming mail). I've personally seen large (>20,000 messages) spools flushed by Sendmail and Postfix, and Postfix was easily twice as fast. YMMV.

If you stop and think about it, this hard-disk required issue produces a bottleneck for any single server. A RAID array or SAN device could provide higher disk throughput, but you're still bound by the single server's file system capabilities. If you need high performance email transfer, building a mondo vertically-scaling server is not the answer; rather, look at a horizontally-scaling cluster of low-cost, low-power boxes. The big box might make sense for a mail store, but it's not suitable for an MTA.

A journaling filesystem like ReiserFS or Ext3FS is recommended. ReiserFS's focus on great performance for many small files is particularly compelling for an MTA, though ReiserFS is another of those products which inspires either love or hate. Additionally, putting the mail spool on its own hard disk or a RAID stripe set will produce the best performance (what kind of RAID is a question for another day -- my recommendation is RAID0 or RAID1 for a relay server and RAID5 with a hardware array controller for a mail store).

Last modified: Oct 24, 2008 2:28 pm. Contact me.