Chapter 3. Comparison With Other Popular MTA's

sendmail

In the right hands, can be quite a flexible tool to translate between the different conventions of various networks. Unfortunately this is accomplished by programming in an unfamiliar production language containing many magic features. The learning time for doing this is very long, the effort involved is that of learning a completely new language and environment. Moreover, Sendmail has all major components built into a single large program. Both of these design decisions have been acknowledged as mistakes by the author of Sendmail. Its major shortcoming in comparison to the MMDF mailer is its primitive database facility and lack of caching.

sendmail 8.x

Since long time of no development, sendmail got a developemnt boost around mid 1990'es, which has made it somewhat better, but still the principal queueing model is the same as always.

MMDF

MMDF is a comprehensive mail environment, including its own mail composition program and of course a mailer. There are too many parts to it as can be said, it is a system, not a subsystem), and the address manipulation is only sufficient for a relatively homogenous environment. It does have reasonable database facilities and caching, as opposed to Sendmail, and the concept of Channels. However, knowledge about address semantics is distributed in several programs instead of being centralized.

PMDF

PMDF was originally a smaller version of MMDF with correspondingly reduced features and flexibility, but it has had years of development since late 1980'es, and its commercial version is amongst the high performers of MTAs in late 1990'es.

Upas

Upas is a curious approach to the problem. It lets the user do half the work of message routing, in a manner similar to PMDF on VMS systems. It is entirely concerned with the message envelope, and leaves all message header munging to auxiliary programs if appropriate. In fairness one should note this mailer was developed in an environment where most message headers were scorned, thus making this a reasonable approach (``optimize the normal case''). The Eighth Edition Upas had no database capability at all, but it did exhibit one useful characteristic: the routing decisions are made by passing the recipient envelope address through a set of regular expressions. This production rule approach is similar to what Sendmail does, but uses a more familiar mechanism and environment.

Smail 3.0

Another recently developed (late 1980'es), mailer worth mentioning here is Smail3.0. It is intended as a program capable of replacing Sendmail in many situations. To a large extent it succeeds as this, and there are some nice ideas involved as well. Its two major drawbacks are that it is not as easy to adapt to local needs as Sendmail is (compiled instead of interpreted rules and algorithms), and retaining Sendmail's single-program design. It addresses database and caching issues, and seems generally like a nicer design in many respects, a bit like PMDF's configuration options in a Sendmail package.

Smail 3.1

Further developemnts for Smail 3.0.

Exim

http://www.exim.org/

A post-developemnt version of Smail.

qmail

http://www.qmail.org/

postfix

http://www.postfix.org/

Until the recent increase in the demand for inter-network mail gatewaying, Sendmail's flexibility had quite adequately served to implement a gateway function between selected networks. With increased variety of the normal address syntax and mail capabilities of connected networks, and more complex kinds of routing decisions becoming necessary, the existing mailers have been showing their age and their limits. ZMailer is intended to give the mail administrator a software tool that fits the times.

3.1. Feature comparisons of MTAs

This section is adapted from 's MTA comparison experiment report at http://www.kyoto.wide.ad.jp/mta/eval1/eindex.html

Table 3-1. MTA feature comparisons

MTA nameDNS ConcurrencySMTP ConcurrencySMTP Pickybacking
ZMailer 2.99.53Good (fork, AD-data)Good (fork)Weak (domain only)
PostFix beta 19990122-pl01? (?)Good (fork)Weak (by domain)
sendmail 8.9.3No (partial)NoGood (MX list)
qmail 1.03Good (fork)Good (fork)None
smail 3.2.0.101No (AD-data)NoWeak (by domain)
exim 2.053No (AD-data)Good (fork)Excellent (by MX hosts)
SMTPfeed 0.95Good (threaded, AD-data)Good (threaded)Excellent (by MX hosts)

DNS Concurrency

The ``DNS Concurrency'' exists in a few forms:

Good

Concurrent

No

Not concurrent

threaded

Single process doing it all via threads

fork

DNS lookups happen at forked subprocess

partial

sendmail does MX RR lookups before any SMTP deliveries, and the A RR queries are made only when connection for some server is desired.

AD-Data

DNS reply ``ADDITIONAL SECTION'' data is used so that in most cases the MTA does not need to ask for more data (A-records)

SMTP Concurrency

The ``SMTP Concurrency'' exists in a few forms:

Good

Several parallel transmissions are happening

No

Operation is serialized

threaded

Single process doing it all via threads

fork

SMTP connections are done by forked subprocesses

SMTP Pickybacking

In which way the MTA bundles together transmitted messages into as few SMTP sessions as possible:

Excellent (by MX hosts)

If two destination domains for possibly several messages can be delivered via same remote end server as they have same server host in their MXes, deliver both addresses/messages via the lowest of the same MX servers.

Good (MX list)

If two destination domains have same list of MX servers in similar precedence order, deliver those messages thru same connection.

Weak (by domain)

Deliver only those messages which recipients have same domain thru same SMTP connection

None

Deliver each message/destination individually, no parallellism at all.

In fact the qmail delivers each recipient in separate SMTP connections.

placeholder text