Browse by category
Search | Advanced search
This article was adapted from www.lwn.net -- published in August, 2006 with many contributors on LWN and since then.
For a lot of people the choice of the Mail Transfer Agent is important. A bad choice can mean lost time and money, lower reliability and increased risk to networks. A good choice can, depending on the architecture of your mail system, remain substantially unchanged for years. If you're designing a major mail system then you're also going to be asking yourself the question should I use more than one kind of MTA, and if so which should go where? Hopefully this article can help.
Too busy? Don't care about the pros and cons? Here is the Quick Answer.
I only cover MTAs related to Unix/Linux, and where these MTAs have leaked onto other operating systems. If you are planning to run a mail system on something else then you have specialist needs, or you have a problem, or both.
Debates over MTAs sometimes last for years, and this article covers the main points that come up over and over. Unfortunately, apart from this article there are no general comparisons of MTA characteristics on the Internet, and even very little benchmarking. The remarks here are personal opinions drawn from readily-verifiable facts and subjective comments drawn from experience. Nearly every MTA has a vociferous and sometimes combative group of supporters, not always including the principal authors of the MTA.
It is easy to see why administrators care about which MTA they use. Large installations require a lot of time spent tuning the MTA, and for any site email is commonly regarded as the most important use of the Internet. End users can get by without a web site or a browser for a little, but without email business stops. And so countless administrators invest time in learning how to tweak their internet mail delivery tool in order to meet their various goals. But which tool should they use when?
As at the beginning of 2007, most Internet email seems to be delivered by one of four MTAs:
There are other worthy free MTAs to talk about, such as zmailer and smail3, but since they are not so widely used I omit them. There are some MTAs that are a small component of a larger system such as Courier-MTA (despite the name, which doesn't fit any definition of MTA used here!) which it isn't reasonable to compare. There are some unworthy MTAs too, these I am delighted to omit. There are also changes afoot I expect to cover here soon, including the rise of blackbox front-end email systems and new MTAs making their debut.
Current and recent versions (say, since 2002) of each of these four widely-used MTAs have broadly similar features. All of them have, on the basis of a very large body of evidence, the following characteristics:
There are some assumptions implicit in the rest of this article. This document is not for you if you are looking for a product that:
Lotus Notes and Microsoft Exchange are examples of systems that don't meet the criteria for this document. They are able function as MTAs, but that is only a small part of what they were designed to do.
No MTA scores well by all measures. The needs of users vary greatly and some criteria are mutually orthogonal. Commonly cited MTA selection criteria are:
Design features partly decide how much each MTA meets these criteria, with the rest coming from where the development team have interests. Contradictory examples of these features are:
These features are all valid. Which features you need depends on what you're looking for.
Just about every mail delivery scenario can be met, in one way or another, by all four MTAs. There is no one right answer.
There is no equivalent of the Netcraft Web Survey for SMTP servers. SMTP surveying is a very different task to what Netcraft (and other companies) do for the web, but not particularly harder. It is astonishing how little definitive information there is about what SMTP servers are in use on the public Internet.
I picked the Big Four MTAs for this article based on discussions with the people who run busy mail hubs in public ISPs, by lurking in the email community and from taking small samples of what is running behind the world's MX records. I also take into account that many administrators do not change the MTA that comes with their Unix-like operating system. No major Linux distribution ship Sendmail by default, except for Red Hat prior to 2007, and only Sendmail on commercial Unix and some BSD platforms. Indicators such as the Debian Popularity Contest are flawed as statistical measures although they can give a flavour of what is happening in one corner of the Internet.
In January 2007 an article was published with the hopeful title Fingerprinting the World's Mail Servers and it illustrates that SMTP surveys are not so easy. Despite making what appears to be a very competent effort the authors settle for sampling 400k domains belonging to companies listed by a US data firm. While interesting, this data clearly cannot tell us which SMTP servers are run on the Internet. I have asked Ken Simpson and Stas Bekman if they would mind sharing their detection code for incorporation into a more complete survey design.
Dan Bernstein's 2001 SMTP survey of one million hosts put Sendmail at about 42% market share, but the methodology described is unlikely to give representative results for the Internet as a whole. Like the Simpson/Bekman article there is only an overview description of the approach, so it cannot be replicated.
|Goals:||Security; Simplicity; Efficiency|
|Non-goals:||Unix conventions, ease of admin|
|Licence:||not open source or free|
|Config:||Many simple control files|
|Releases:||Never (since 1997!)|
|Flexibility:||Very, if you study hard|
|Administration:||Buy one of the books!|
|Community:||Smallish but very active|
Note: qmail is unmaintained: the author has not released since 1997 and does not permit others to make releases. It is also not Open Source Software, although the source is visible and usable within very tight restrictions.
So why should anyone care about qmail? Perhaps they shouldn't in 2007, but there were good reasons to notice qmail in its first five years of life, and there is still considerable publicity surrounding it, and some very happy users:
These days these advantages are at least equalled by other MTAs, and Maildir has become Maildir++. Yes, qmail taught MTA users and developers some lessons. No, qmail isn't reagarded as a realistic option these days: it doesn't support modern mail standards or even IPv6; it isn't maintained; it isn't possible for someone else to maintain it; its many oddities are increasingly painful relative to any benefits qmail has.
In 2007 a qmail maestro is someone who knows which collection of patches to apply to a ten year-old program. In 2004 a group of qmail experts put together netqmail, a distribution of qmail patches. But even that hasn't been touched for years, and now there are patches for the netqmail patch collection. Then there was qmailrocks which claims to be superceded (with a non-trivial upgrade path) by the author of the patches used by qmailrocks. Someone has pointed me to qmail-ldap as being used by ISPs. As observed at the beginning, you can use qmail to build a significant mail hub. But with the requirement to negotiate the chaos of qmail patch sets, you need to have a very special brand of dedication to ensure your mail hub is a good one. You might find qmail works for small sites without much configuration, but that will entirely depend on how your particular email workload is skewed -- for example, you might suddenly become invisible to some of your customers due to backscatter spam.
qmail is still used on some very high-volume sites, and there are still people who strongly believe that qmail is very correct code. qmail source is legal to copy, use and patch. The author's licencing analysis is thought-provoking but thus far irrelevant to the global copyright debate.
qmail comes with more free personality than nearly any other program -- what other MTA is likely to ask "hath the daemon spawn no fire?" when it can't start?
|Goals:||Security; Easy of use; Standards|
|Non-goals:||General purpose MTA|
|Licence:||IPL (a disused license)|
|Config:||Single control file|
|Flexibility:||Easy to change|
|Administration:||Intermediate, good docs|
|Security:||Good record. Credible team.|
|Sendmail compat:||Very good|
Design goals: Secure, easy to administer, efficient.
Postfix is, like qmail, written by a prolific Unix security software author, this time Wietse Venema although unlike qmail the result is a suite with an interface like most other Unix programs. Postfix is almost entirely the work of Wietse, with occasional contributions in isolated areas such as integrating the Transport Layer Security (TLS) libraries. Releases come in bursts, with some releases containing only very small improvements. Release management is by Wietse personally.
Postfix has a monolithic main configuration file like Exim and Sendmail. It is table-driven, everything is a table and a table can be represented in all kinds of ways from plain text files to databases to relational databases and more. It handles regular expressions in many contexts, using the Perl Compatible Regular Expression library developed by Phil Hazel for Exim. Postfix consists of about 150k lines of code.
Postfix fits somewhere between qmail and Exim. It consists of several programs (but fewer than qmail), and has a monolithic configuration file. Postfix has a strong emphasis on security, but not to the extent of imposing unusual Unix management practices. Postfix is quite flexible in its configuration file, but not to the extent of Exim. Postfix postdates qmail and follows a vaguely analogous security approach, an approach which was relatively more important in 1997. The Sendmail team explicitly acknowledge Postfix as an influence on their next-generation replacement for Sendmail, MeTA1.
Postfix is less versatile than Exim, and this is largely due to its foremost design criteria being security. Wietse specialises in writing software that is demonstrably harder to break, and that design goal prohibits some very convenient features that Exim can offer. Postfix is further towards the paranoia end of the security spectrum than Exim or Sendmail. The impressive achievement is that Postfix delivers such great flexibility and ease of administration despite meeting strict security goals. qmail is also regarded as highly secure, however it does not, by design policy, give the administrator anything like the flexibility of Postfix. If you have good reason to be paranoid, these sorts of considerations may mean that in a mail architecture you use Postfix for Internet-facing services and something else behind it.
Postfix has been measured by many as being extremely fast, and I have found it very efficient. My impression is that it is more efficient than Exim but not to a noticeable on modern hardware degree even with very high load. Postfix and qmail seem to use about the same amount of memory but by deliberate design qmail uses more bandwidth than Postfix because qmail only ever sends a single message per SMTP session even if there are multiple messages going via the same host. Postfix is quite Unix-centric with its secure design and is not maintained on very non-Unix platforms such as Windows.
Postfix is, like Exim, a drop-in replacement for Sendmail. Besides just implementing the sendmail command line interface, Postfix is compatible with Sendmail milters, an impressive and unequalled achievement to those that have investment in such modules.
The Postfix community is very active. Online documentation is quite good but scattered. There are three Postfix books in English.
|Licence:||Bespoke Open Source|
|Config:||Single control file|
|Flexibility:||Enormous, but complex|
|Administration:||Hard to do well|
|Security:||Terrible. Better now.|
|Performance:||Ok for many|
|Sendmail compat:||Bug for bug :-)|
Design goals: Current Sendmail must be backwards-compatible. (The forthcoming MeTA1 project, formerly Sendmail X, is a rewrite and has design goals similar to Postfix.)
Sendmail 8 consists of about 118k lines of code, but that does not count the functionality in the M4 scripts used to generate the config file, nor milters. Documentation is good, and uniquely among MTAs there is a dominant company dedicated to Sendmail services. The Sendmail Consortium is dedicated to maintaining the Sendmail codebase.
Sendmail has an extraordinarily obscure configuration file, a poor history of security breaches and a design centred around Unix in the early 1980s. Sendmail is known for being inefficient compared to alternatives so it might be hard to see why sendmail is still used at all, but history has its own inertia. There is no good reason for a site without Sendmail experience to install it, given the effectiveness of the alternatives. There are often good reasons why a site with Sendmail working should keep it.
Despite all this, Sendmail:
Sendmail has been ported to many systems, including some that are not Unix-like such as Windows. Postfix isn't realistically portable to Windows, and Exim is something of a second-class citizen on Windows since it runs via Cygwin. So portability might be a reason to run Sendmail.
|Goals:||General purpose MTA|
|Config:||Single control file|
|Sendmail compat:||Very good|
Design goal: General-purpose MTA for Unix machines.
Exim was inspired by the author's work with the smail 3 source code, which was itself provoked by the many problems of sendmail. So Exim too is a Sendmail drop-in replacement.
The outstanding feature of Exim is the intention that it be a general-purpose mailer. Exim is not a total rethink about how mail works, like qmail is. Nor does it restrict its feature set in order to achieve theoretical security, like Postfix. Exim instead tries to give administrators what they asked for, with of course a strong interest in security, reliability and performance. Exim cannot ever be considered as secure as Postfix, but then, it seems to be quite secure enough for most normal applications. Of the many compromised Unix machines I've met quite a few have been running Exim but there was no suspicion that Exim was the cause of the breach. Think about this carefully, a lot of people mistakenly view security as an absolute where it is instead a continuum. In exchange for a lower level of design security -- for example, a willingness to cooperate with unknownable external programs for handling messages throughout message processing -- you get versatility Postfix cannot deliver. The counterpart to this paragraph is in the Postfix section. As a historical footnote, Exim3 had some flaws and consequently a couple of serious security breaches. Exim4 has a different design and has not had serious issues.
Exim behaves much like any traditional Unix daemon, with a monolithic configuration file, a monolithic daemon, small number of log files and a standard style of spooling. It has a very good security record over the last seven years (early releases had classic security issues), can cope with high load, and it has excellent integration facilities. Exim can be extended in many ways - it is even possible to compile in the entire perl interpreter to call from the configuration file! If there is an MTA feature, then Exim can support that feature in some way or another. Exim is very tightly specified and documented. Many features can be omitted at compile-time, making a special-purpose Exim easy to create. Exim has its own filter language, implementing the functionality that procmail most commonly use plus some extras.
Exim is used at some very high-volume sites where it provides good service, so performance comparisons saying qmail and Postfix are faster and handle queuing better don't necessarily have any bearing on real-world conditions (in 2007 on current hardware and with current definitions of high load.)
A split MTA architecture is often useful. For example, separate MTAs for each of:
There are efficiencies to using just one MTA, including in human resources and potentially reduced human error. Equally there can be good reasons to choose different MTAs for different purposes.
One scenario is to use Postfix and Exim. The logic for Postfix is that an MTA facing the Internet needs to be as secure as possible it must perform as few functions as possible. For Exim, an MTA used to maximise the quality of email in a second level of anti-spam/malware must be as flexible as possible.
Where there can be disc I/O performance problems, another scenario is to use just the delivery portion of Postfix for local deliveries because it is relatively small and fast, and Exim for everything else.
For sites already running Sendmail but experiencing performance problems it can help to leave all the routing logic to Sendmail (with the configuration files developed over many years) but to do the intensive spam/malware processing with either Exim or Postfix.
One of the interesting things about the three non-Sendmail MTAs here is the ideas and code that are shared. Postfix uses the Perl Compatible Regular Expressions library developed for Exim. Exim understands the Constant Database Format developed for qmail, and the Maildir mail file format also qmail. Postfix can use the Constant Database Format, and can use Sendmail Milters. And the successor to Sendmail explicitly acknowledges design inspiration from Postfix and qmail.
The reason - not the biggest but the only - reason why Unix MTAs have to work so hard at security is because of the Unix tradition of local delivery to files owned by an individual user. There is a kind of collective Unix racial memory relating MTAs to high-risk operations. Anything listening on port 25 must have root privilege because it is a privileged port, but all kinds of other servers have the same issue including web servers.
The MTA mixture of setuid binaries, specially-owned directories, pedantic authentication of local destinations, paranoia over filesystem access is all to do with having the MTA write to a file owned by some other user, usually by impersonating that user. Of course that is fraught with potential danger, and no matter how well the code is written a careless administrator can still make the entire process unsafe by changing file permissions. It can be difficult to impose modern partitioning security schemes on top of traditional Unix local delivery too.
But in millions of sites this is no longer an issue, because mail is kept in a central (usually IMAP-accessible) mailstore until the user chooses to view it. Mail comes into the SMTP daemon, which then makes an LMTP delivery to the IMAP daemon. Nothing touches local files. You can run the daemon as user nobody. It is possible to configure at least three of these mailers so that none of the potentially dangerous code is even on your system. Here's how:
The answer is Exim. If Exim doesn't do it for you then look at the pros and cons and don't read this section :-)
Exim can solve any MTA problem at least well and often excellently, has very good documentation and a most supportive community. It is the only modern mailer to expressly aim to be general-purpose. That is why it is always the best default recommendation. There are no ordinary circumstances where Exim is a bad choice, although there are circumstances where something else will clearly be better.
Think of Exim as the Linux of free MTAs. There are many free Operating Systems and some of them are better than Linux for specific tasks. But Linux can do (at least) a good job for nearly everyone.
This table is a bit less of a blanket statement:
|if you are...||qmail||Exim||Sendmail||Postfix||Notes|
|Inexperienced||0||3||1||3||Exim and Postfix have good docs and clear examples|
|Worried about security||3||2||0||3||Postfix is secure and modern; qmail is secure but very old and cranky; Exim is secure to different criteria (read above.)|
|Relying on Sendmail milters||0||1||3||2||Postfix can run milters; can use equivalent Exim routers/filter script|
|Wanting minimum hassle||0||3||0||3||Sendmail has some easy front-ends, but the deeper you go the worse it gets. Postfix and Exim are more predictable.|
|Resource-constrained||3||2||1||2||See Embedded Application below for other comments|
|On Windows||0||2||3||0||Sendmail has a native Windows port; Exim is in the Cygwin distro|
|Needing commercial support||1||3||3||3||There are competent companies for all MTAs; qmail is inherently less supportable being so old|
This article is not about embedded MTAs, mail servers running on tiny boxes, mobile phones etc. However several commentators have taken exception to my weightings under Resource Constrained. It isn't as simple as you might think, and these weightings can only be illustrative. Here are points to consider: