Prefatory notes: (1) You may not need or want a full-featured MTA, if your machine does/should hand off all outbound mail to a nearby Internet mail server relay. If so, please see: http://linuxmafia.com/faq/Mail/nullmailers.html. (2) The e-mails quoted below have in some cases been re-edited to update them.

From plug-admin@lists.q-linux.com Wed Sep 18 15:27:27 2002
To: plug@lists.q-linux.com
Subject: Re: [plug] email server question...
User-Agent: Mutt/1.4i
From: Rick Moen <rick@linuxmafia.com>

Quoting Ian C. Sison (ian.s@qsr.com.ph):

> And of these points not a single ONE of these address anything
> technical in nature,

Technical comparisons of MTAs (Mail Transfer Agents, i.e. SMTP daemons) are difficult; meaningful ones, more so, because much is inherently debatable. Even the comparisons of throughput capacity I've seen have been such. (See remarks by J C Lawrence in the middle of sendmail.html.)

Qmail (like Postfix) benefits from carefully modular design, with attention paid to trust relationships and the nature of inter-modular communication. (By comparison, both Sendmail and Exim both spawn as SUID-root processes, then drop privilege according to the role of each process. Many comments commonly seen about Sendmail are outdated in failing to credit it with that improvement: Sendmail processes formerly always used root privilege regardless of role. Fixing this design flaw seems to have very dramatically improved Sendmail security.)

Per J C Lawrence, Qmail, Postfix, and Exim all seem to generate similar throughput numbers, with difference in system loading characteristics. Sendmail's in the same ballpark, but with less well optimised delivery and spooling. (Again, it's alleged that Sendmail's been improved in those areas.)

Postfix and Exim both support all of Sendmail's command-line modes, which means either is a drop-in Sendmail replacement (once you have a suitable conf file). Qmail supports some of the switches, but not all.

Qmail can be made to support mbox format (via modifications to /var/qmail/rc to support procmail as your MDA (Mail Delivery Agent), or possibly other MDAs such as maildrop); author Dan Bernstein disapproves of mbox format, so you have to customise.

Patches: Because of Dan's licensing (see below), third-party Qmail patches effectively never get regression tested against one another. In my experience, departing from the Dan-approved way, generally, tends to cause headaches. To pick one of the more extreme examples: Making it FHS-compliant would be a career in itself. (Not coincidentally, Dan disapproves of the Filesystem Hierarchy Standard.) [Dec. 2007 update: Dan has retroactively declared qmail 1.03, along with djbdns 1.05, daemontools 0.76, djbfft 0.76, ezmlm 0.53, dot-forward 0.71, fastforward 0.51, primegen 0.97, and ucspi-tcp 0.88 to be public domain.]

Starting 2004, a group of talented qmail developers have released netqmail — Bernstein's 1998 qmail v. 1.03 source code release (effectively abandonware, after these many years) with a huge omnibus patch and build system: It is an impressive achievement, but underlines the licensing-based limitations [Dec. 2007 update: limitations that are now gone]: Neither they nor anyone else may fork the codebase in any regular, reasonable way, nor ever lawfully distribute any sort of binary. [Dec. 2007 update: Foregoing is no longer true.]

Sendmail sports the Configuration File from Hell -- which in theory you can avoid by working only with m4 files. But somehow, everyone keeps getting sucked back into directly modifying sendmail.cf .

There are still some types of rewrite rulesets and delivery modes that only Sendmail can do. (UUCP used to be a leading example; recently, Postfix and Qmail, at least, have been used with that delivery mechanism.)

Arguments based on security history are dubious, for multiple reasons including failure to take into account fundamental changes (such as newer Sendmail versions dropping privilege according to process role) after some past incidents.[1] (If one were to judge MTAs on the basis of past exploits, then any brand-new MTA would automatically win without regard to merit.)[2]

Build problems: Exim is/was reputed to use a rather eccentric and brittle Makefile setup. (Can't comment, and, if this was true, I'm not sure it still is.) Qmail suffers the peculiarity that Dan doesn't believe in automake/autoconf at all, and consequently his coding style is really strange and difficult to read, let alone port. It's not just that all source-code files are in a single directory; it's not even that the man writes his own custom replacement for stdio.h(!) -- you really have to try to read his code to understand how peculiar it is.

If you run the GNU Mailman mailing-list manager, Exim has really seamless, easy, automated integration with it. (All four[3] MTAs will work well enough with the general run of mailing list software -- Mailman, Listproc, Listserv, Majordomo, Majordomo2, Sympa -- with varying degrees of hassle. Qmail can additionally work with ezmlm, which is Qmail-specific and closely integrated.

Exim can be made to perform SpamAssassin checks on incoming mail during the SMTP transaction, letting you reject detected spam without even accepting delivery: http://marc.merlins.org/linux/exim/sa.html

Both Qmail and Postfix have easy virtual host support, and in general have administrative characteristics that scale well to large sites. Exim's configuration/administration is perfect for small sites. The configuration files for Qmail one either loves or hates; they're eccentric, in any event.

Qmail's mail spool cannot[4] be backed up or migrated to a different host, because it uses inode numbers in spool filenames. (Dan feels this is justified for performance reasons.) Postfix does more or less the same thing.

Last, of course, Qmail is [2007 update: was] the only one of the four under a proprietary (albeit generous) licence -- the main consequence of which is that the project cannot be forked, and that if/when Dan loses interest or dies, without some additional licence grant the package will become effectively unmaintainable and a dead project. [2007 update: Foregoing is no longer true.]

Likewise, modified Qmail may not be distributed (except as patchfiles), nor may Qmail be ported, without Dan's explicit permission. [2007 update: This is no longer true.]

Qmail itself was last maintained in 1998 (version 1.03): It has become abandonware, in effect, with the licence preventing [2007 update: used to prevent] anyone else from taking over maintenance and development.

[1] The people most often guilty of this fallacy are Qmail advocates, who also will characteristically speak only of Qmail/Sendmail comparisons, whereas the most-natural comparisons would be Qmail/Postfix and Exim/Sendmail, on account of design category (modular vs. monolithic). My guess is this is mostly a holdover habit from the days when Qmail was the sole significant challenger to Sendmail's status as the default, standard MTA. However, it's also true that Sendmail is an easier, more-facile debate target than is Postfix. To that extent, this Qmail-fan-trademark debate tactic of targeting poorly-briefed Sendmail admins, and failing to inform them of the obvious third alternative, is a serious disservice to the latter.

Ditto Qmail advocates' tendentious habit of begging the question by labelling designs differing from Dan's (e.g., Sendmail and Exim's being monolithic binaries that drop privilege according to role) as "not correct design". It is fallacious to try to decree security outcomes ex-cathedra by pronouncing a design "not correct": The proof is always in the pudding.

[2] If one is studying MTA history regardless of its dubious relevance, one should be aware that Postfix had an extensive early history under its original name, VMailer, when it was a project mostly internal to IBM Corporation.

[3] Courier-MTA, http://www.courier-mta.org/, should also be included in this discussion, but I don't know enough about it.

In addition, as of 2007-10-20, a ground-up rewrite of Sendmail, as a modular MTA (i.e., similar to Postfix or Courier-MTA) called "MeTA1", (formerly "Sendmail X") has been released (1.0.PreAlpha21.0) as a candidate sendmail successor. Dovecot imapd author Timo Sirainen commented on the initial design. (Warning: unmaintained page.)

[4] No longer true: Workarounds have appeared in the form of either of two third-party utilities, queue-repair and queue-fix, both findable via http://www.qmail.org/top.html. Either will let you migrate or back up Qmail queue contents without lossage. My thanks to Dek likot@yahoo.com on the PLUG mailing list for pointing this out.

 
-- 
Cheers,                                             Live Faust, die Jung.
Rick Moen
rick@linuxmafia.com

From rick Tue Aug 6 16:56:00 2002
Date: Tue, 6 Aug 2002 16:56:00 -0700
To: balug-talk@balug.org
Subject: Re: [Balug-talk] Re[2]: [svlug] mail relaying, jitterbug and me
User-Agent: Mutt/1.4i

Quoting Bill Moseley (moseley@hank.org):

> Can anyone give a basic overview of the differences between Exim and
> Postfix, and when one would be preferred over the other?

contra_majordomo_plus_MTA_stuff.html (formerly at http://www.grin.net/~mirthles/pile/contra_majordomo_plus_MTA_stuff.html — mailing list thread from Sept. 2000)
http://phaseit.net/claird/comp.mail.misc/MTA_comparison.html (by Cameron Laird; unmaintained since 1999)
http://mailsoftware.cjb.net/ (occasionally updated, most recently Nov. 2003)
http://www.zmailer.org/zman/ztut-some-comparisons.shtml (current — maintained by the authors of another MTA I've neglected: ZMailer)
http://www.debianplanet.org/node.php?id=641 (2002 thread comparing popular MTAs)
http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/ (2004 write-up by qmail fan Jonathan de Boyne Pollard)
http://www.geocities.com/mailsoftware42/ (2003 comparison by an anonymous Geocities user)
http://shearer.org/MTA_Comparison/ (comprehensive, lucid comparison of the four top MTAs, by Dan Shearer)

ObDisclaimers: 'Ware obsolete data. Mind the gap. Cave canem.

-- 
This message falsely claims to have been scanned for viruses with F-Secure
Anti-Virus for Microsoft Exchange and to have been found clean.

From: Ted Cabeen ted@impulse.net
To: Ralf Dreibrodt rd@mesos.de
Cc: WebMaster neroot@franceonline.fr, debian-security@lists.debian.org
Subject: Re: postfix in qmail out proftpd in pureftpd
Date: Wed, 02 Oct 2002 13:17:34 -0700

In message 3D9B4C3A.F56AFBC0@mesos.de, Ralf Dreibrodt writes:

> I was talking about pureftpd. qmail itself perhaps had no security
> problems, but other programs, e.g. vpopmail or vchkpw, have.

Exactly. IMHO, qmail has avoided many security bugs because it's feature-poor. Many new features that are provided as standard in other mail servers are unsupported patches to stock qmail. Thus, qmail avoids some of the holes that appear in other servers, because they are adding features instead of standing still. However, the underlying design concepts of qmail are quite solid, which is why postfix uses a similar architecture.

That said, they're both very good mail servers, just with slightly different focuses.

- --
Ted Cabeen http://www.pobox.com/~secabeen ted@impulse.net
Check Website or Keyserver for PGP/GPG Key BA0349D2 secabeen@pobox.com
"I have taken all knowledge to be my province." -F. Bacon secabeen@cabeen.org
"Human kind cannot bear very much reality."-T.S.Eliot cabeen@netcom.com

Date: Thu, 3 Oct 2002 00:54:01 +0200
From: Bastian Blank waldi@debian.org
To: debian-security@lists.debian.org
Subject: Re: postfix in qmail out proftpd in pureftpd

On Wed, Oct 02, 2002 at 10:57:55PM +0200, Jose Luis Domingo Lopez wrote:

> At least not for me. But a reward offered 5 years ago that not only
> hasn't been awarded, but even has not even been asked for, maybe is a
> proof of a piece of software without grave bugs in 5 years.

http://home.pages.de/~mandree/qmail-bugs.html

bastian

RM adds: Above URL is a detailed list of unfixed qmail security holes / RFC violations. Elsewhere, a qmail fan posted a point-by-point rejoinder: http://web.archive.org/web/20031101024909/http://www.geocrawler.com/mail/msg.php3?msg_id=9506623&list=513
Most of those rejoinders amount to "Yes, Qmail violates various RFCs and other conventions, but those RFCs and conventions are bad and/or inconvenient."

Additionally, Timo Sirainen, author of the Dovecot imapd, has pointed out several "questionable security holes" in qmail.

The author of Courier-MTA wrote it largely in order to solve the problem of key functionality missing from qmail. See: http://web.archive.org/web/20040605134745/http://www.courier-mta.org/history.html

Late addition: John Newbegin announced on 2002-11-06 that he was beginning work on a GPLed clone of Qmail. Announcement is here: http://www.ornl.gov/cts/archives/mailing-lists/qmail/2002/11/msg00105.html

Date: Mon, 10 Feb 2003 10:53:33 +0000
From: Sean Burlington sean@uncertainty.org.uk
To: debian-security@lists.debian.org
Subject: Re: [personal] securing pop3

You don't have to switch SMTP servers to do this.

The following link describes a method of setting up virtual domains for exim/imap:

http://www.tty1.net/virtual_domains_en.html

I am fairly sure courier-pop uses the same authentication system.

Sean

Date: Thu, 13 Feb 2003 12:11:46 -0800 (PST)
From: Simon Cooper sc@sfik.com
Cc: baylisa@baylisa.org
Subject: Re: Sendmail replacements?

A couple of comments and random thoughts about Qmail, Postfix and other mailers.

- Architecturally, they are different!

Qmail has a master program that starts children who inherit their operating environment (and some control parameters) from the parent. This is part of the design.

Postfix is a gaggle of daemons who communicate parameters via pipes. They do not inherit control characteristics from their parent. The daemons are also suspicious of what they are passed and "validate" all input. This is part of the design.

- The way they are written is different!

D. J. Bernstein (Qmail's primary author) treats whitespace and comments as a non-renewable resource! Much of his code would not be out of place as a submission to the IOCCC. If you need to debug a code problem or want to add a feature, then you'll likely end up spending considerable time doing it.

Wietse Zweitze Venema (Postfix's primary author) writes code which is legible, and with insightful comments. You'll spend less time debugging a code problem or trying to add a feature.

- All of the (major) "religious war" mailers were written either by academics, professionals with a strong academia background, or students.

- None of Exim, Postfix, or Qmail was written by a student who was an undergraduate or graduate student at the time! Consequently, none of the programs gets my labeling as: "graduate-student code" or "undergraduate code". (Both sendmail and bind qualify!)

Having said these things, all of Exim, Postfix and Qmail get the job done.

I run Postfix.

Simon.

To: baylisa@baylisa.org
Subject: Re: Sendmail replacements?
Date: Thu, 13 Feb 2003 12:14:00 -0800
From: J C Lawrence claw@kanga.nu

On Thu, 13 Feb 2003 11:49:45 -0500
Rich Holland holland@guidancetech.com wrote:

> It's been several years since I did any significant SMTP work, and now
> I find that I've got to configure a bunch of machines and a central
> hub to relay mail for the others.

Aye, that's called a "smarthost".

> My first thought was rewriting headers by changing the sendmail.cf
> file, but now that I think about it, this may be the time to replace
> sendmail with something "easier" or "better" or "more secure" but I'm
> out of touch with the state of the art in SMTP mailers.

You're going to be told about Exim, Postfix, Qmail, and Sendmail. Start out by realising that this is a field rife with subjective opinion and preferences reported as fact.

Of the lot above I've used Exim and Postfix extensively. I like 'em both. Shockingly, I like 'em for different reasons and use them in different cases.

Postfix screams (in a non-earwax-drilling way). With minor effort on a $2,000 box, I find I can sustain 2,400 outbound deliveries per minute (to Internet sites across the cloud). That runs up to a few million a day without blinking. The configuration is trivial, well documented, consolidated into two files, and pleasant.

Exim is a delight. Extremely well documented, and configurable out the wazoo. On the same $2,000 box with similar levels of effort to Postfix, I've gotten 2,200 outbound deliveries per minute with similar effort levels.

I run and use both. I like both.

- Exim is absurdly configurable and extensible. It rivals Sendmail for the number of buttons that can be tweaked. Happily the vast majority have intelligent defaults and can be left alone. More happily, it has excellent documentation on the buttons.

- Exim is amazingly easy to integrate with external systems, tools, mail processing systems, etc. Postfix isn't bad in that regard, but Exim is better. As a quick example, for my TMDA integrations I needed alias pipes to be run as a specific UID/GID. That's trivial under Exim and not under Postfix.

- The above point warrants more attention. Exim is amazingly good at integration. SpamAssassin, TMDA, virus scanners, outbound mail processors, per address filtering, system wide filters, you name it. Exim just smiles and asks for more -- and all with a config file you can come back to two years later and understand on the first reading.

- Exim is very friendly to localhost by default. It has a number of knobs for things like system load, number of messages received, etc., that make it easy to keep Exim friendly to other services running on the same box. Similarly, it's easy to configure Exim such that it essentially never impacts localhost operation, even under large spools).

- Exim doesn't handle large spools well. There are a number of things you can do to improve that condition (like split spools), but the baseline remains: If you're heading into the hundreds of thousands of spool entries, Exim is going to start to suffer. There are some ugly contention points on the core control files in Exim that don't improve matters there. Postfix handles large spools with considerably more ease, and has a flatter, smoother scaling curve in that regard.

- Philip Hazel (Exim author) and Wietse Venema (Postfix author) are pleasant, responsive, friendly, and generally good sorts, who are about as much of a joy to work with as you could ever hope for. Both have large active support communities for their MTAs.

I see that Rick Moen (:waves) later quotes a quote of my comments on them, so I'll leave that there. I (and others) have made various comments in the Mailman FAQ that you might find useful:

http://www.python.org/cgi-bin/faqw-mm.py?req=index

> Anyone have any suggestions?

Boy, most people don't invite nuclear strikes.

--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

RM adds: It should be noted that Exim 3.x, familiar to many Debian users, is no longer maintained, and has been replaced with Exim 4.x, a comprehensive rewrite using largely the same architecture but with a slightly different (not compatible) but still very easy to read configuration file.

Some Exim 4.x packagers choose to divide up the unitary exim4.conf file into separately maintainable fragments stored within (e.g.) /etc/exim4/conf.d/ , with a "make"-type shell script provided to [re-]construct exim4.conf from those fragments that can be called as needed or as part of system upgrades.

Your documentation will clarify the matter, but typically there are instructions provided for people who vastly prefer one setup regime (unitary exim4.conf file only versus tree of fragments used to build such a file) to switch from one to the other.

Also well worth mentioning is EximConfig, J.P. Boggis's set of prepackaged configuration, filter files, modifications, and instructions for the Exim4 MTA to make it reject and eliminate spam very effectively, integrating prepackaged Exim4 rulesets (ACLs), SMTP-time invocation of SpamAssassin via Marc Merlin's SA-Exim patch, optional SMTP-time virus-checking and rejection via the Exiscan patch and antiviral software such as ClamAV, optional SPF support to detect and foil Joe-job forgeries, optional greylisting and flood-protection using MySQL, optional spam-scanning of escaped or Base64 encoded message body text using embedded Perl, sender callback verification, optional RBL support, etc.