Sendmail has a difficult reputation. It is the canonical example of how
large, complex programs are subject to security problems. It has a
configuration file format which makes obfuscated Perl code seem highly
readable by comparison. Its performance when dealing with large amounts of
mail is held to be inferior. One could, of course, point out that
sendmail's security problems appear to be mostly behind it, that few people
ever have to look at the raw configuration file, and that sendmail was a
cherished gift, once upon a time, to anybody who had ever tried to convince
delivermail to route a message along a uucp bang path, by way of the
Arpanet, from a CSNet node. For all of its blemishes, sendmail has been a
crucial and valuable part of the network's infrastructure for many years.
After all those years, however, sendmail may just be due for a major
upgrade. As it turns out, work on the next generation of sendmail, called
has been under way for some time. Some early code has been made available;
sendmail X 0.0.16 is available from this page. Do note that
it is billed as "pre-alpha" code; using it on a server which handles real
mail is probably not a good idea.
lengthy design document for sendmail X is available; it gives some
insight into what the next version of sendmail will look like. The first
impression that comes out is that sendmail X will be so different that
one wonders why the "sendmail" name is being used at all. Sendmail X
is a completely new mail transfer agent, redesigned and rewritten from the
As is the norm for contemporary MTA design, sendmail X is implemented
as a set of (relatively) small, cooperating processes. The system is
divided in this way:
- The queue manager is the core of sendmail X; its job is to
manage messages as they move through the system, make delivery
- The SMTP server accepts incoming mail from the net and passes
them to the queue manager. Actually, the queue manager is involved
throughout the SMTP conversation; it is consulted on whether to accept
the connection in the first place,
and it may have actually delivered the mail before the text is
- The SMTP client passes mail on to other systems for delivery.
- The address resolver is charged with understanding - and
rewriting - recipient addresses. This process also handles DNS
blacklisting and other types of address-based filtering.
- The master control program gets all of the other processes
going and handles termination, restarts, and crash recovery. This
program is actually derived from the BSD inetd source.
In addition, there will be a collection of local delivery agents, mail
filter processes, etc.
Much thought has been given to performance, to the point that may cause
some to wonder if there might be some premature optimization going on. For
example, the SMTP server has been designed to use an Apache-style mode,
where multiple processes exist, each of which runs several server threads.
This design will certainly add complexity to the server, but few sites are
likely to benefit from the associated performance increase.
System administrators will be glad to know that the sendmail.cf
configuration file is gone. Sendmail X will use a C-like
configuration syntax, similar to that used by BIND. Configuration of
real-world mail systems will, perhaps, never be an entirely simple task, but
sendmail X should be easier to set up than its predecessor.
Unsurprisingly, security is said to be a core design goal. The
multi-process design is clearly motivated by security concerns, though the
relatively high level of interaction between these processes may complicate
things. The qmail design, for example, has a far lower level of
interaction and trust between its components - though that approach leads
to problems of its own. There are no setuid programs in
sendmail X. It is necessary to run the master control program as root;
it then handles any privileged tasks that it can before starting the
subsidiary processes under a different user ID. Thus, for example, it
binds to the SMTP port before starting the SMTP server. Since the master
control program does not actually handle mail or communicate with the
outside, it should be relatively hard to compromise.
The code consists of almost 600 C files. In some ways it resembles the
qmail code; it has many short files with reimplementations of many
functions normally found in the C library. A special string type is used
to avoid buffer overruns. A casual look suggests that the code really is
being written with security in mind. That much new code is sure to have a
surprise or two in it somewhere, however.
The author of sendmail X (Claus Aßmann) claims to have been running it
since the beginning of the year without losing any mail. Even so, it will
probably be some time before it is put forward as a viable option for
production sites. What happens then will be interesting. Sendmail X
will be jumping into an environment where several other options exist and
are in wide use. The MTA ecosystem has, over the years, gone from being a
single-program monoculture to a diverse field with several alternatives.
Sendmail X will have to be significantly better than those
alternatives, and much better than sendmail 8, to be widely successful
in that environment.
(Thanks to Xose Vazquez Perez for drawing our attention to this project).
to post comments)