One of the longest-lived freeware projects that I have worked on has been the maintenance of Smail-3.
Smail-3 is an implementation of an Electronic Mail Transport Agent (MTA), i.e. a program used for sending and receiving electronic mail, for Unix-like (POSIX compatible) systems.
Smail's job is to accept mail messages from local files or programs running on the local machine (such as any mail user agent), or from remote hosts by way of network protocols such as SMTP or UUCP, and deliver those messages to the appropriate destinations, be they to remote hosts or to files or programs on the local machine. Smail-3 can also gateway e-mail traffic bi-directionally between disparate underlying mail transport systems, for example between SMTP and UUCP.
Smail is designed to be mostly compatible with sendmail in terms of its command-line interfaces and general capabilities but Smail uses a much simpler, cleaner, and hopefully more human friendly, style of configuration files than does sendmail.
In fact Smail-3 is primarily known as one of the most simple to understand and easy to configure modern mail transfer agents. Its out-of-the box configuration is quite suitable for almost any small to medium sized domain and it can be used with little or no local customization.
Smail-3 has also proven to be a capable MTA that can meet the demanding needs of medium sized businesses and ISPs. Even a modest old P-II PC-class server running with Smail and a decent mail store such as Cyrus IMAP can handle all of the e-mail needs for tens of thousands of users provided it has a decent and fast disk subsystem and enough RAM. When running on enterprise-class hardware, Smail will provide enterprise-class service.
Smail-3 has relatively strong security (at least for a big monolithic program that often runs with superuser privileges) as it was implemented using many secure and safe coding practices that avoid most of the common pitfalls of similar large programs written in C. As far as I can tell it has only ever been the subject of one security advisory. Smail also has very good defenses against network abuse such as denial of service attacks. As part of those defenses Smail also offers extensive access control features and filtering capabilities that can be used to block unwanted junk e-mail. These features include many types of basic access control lists for implementing policies for SMTP clients, the ability to use DNS based access lists (both IP and hostname based) for various SMTP parameters, as well as full regular expression (using PCRE) matching on content with separate passes for message headers and message bodies. Smail can also do various DNS consistency checks on client mailers and the SMTP envelope sender address (including doing anti-spoof protection for sender addresses in locally deliverable domains).
Note that Smail-3 is not intended to be a user interface for reading and submitting mail — it is instead the interface to the network and mail delivery systems that those mail readers use. Smail is also not a mail store and does not provide services such as POP or IMAP — but you can use Smail with something like Cyrus IMAP for that purpose.
Smail-3 has many features!
Included in the source distribution is a full set of up-to-date manual pages documenting all of the details about Smail. There's also a somewhat out-of-date user's and administrator's guide in the source too. The latter, even though out of date with respect to the fine details about new features, should help with understanding the general theory of operation of Smail overall.
You can fetch the latest code itself by FTP from the master site at:
A pkgsrc-compatible set of modules which matches the latest release is also available here:
You can sometimes find un-released previews here (if you unpack the pkgsrc shar file it will reference the latest preview automatically):
Smail is listed on freecode.com at
The Free Software Foundation's GNU Project has a very minimal little page describing Smail here:
and another entry in their software directory here:
There is a reference to Smail in the dmoz open directory project:
You can read about any ideas I've recorded for possible future implementation in the online copy of the ToDo file. This file will also document any critical bugs or issues that remain to be fixed before the next release.
There are several low-volume mailing lists for Smail, with the most
commonly used one being the
Smail-3 User's list.
You have to be subscribed to the list in order to post to it. You can
subscribe to it by sending a subscription request message to
I also actively support those of our customers who are using Smail, providing them with both programming and support services.
Note: This problem was fixed very early in the release cycle for Smail-184.108.40.206.
A heap-based buffer overflow has been discovered in the nether regions of Smail -- some ``be liberal in what you accept'' code that's been hanging about unchanged since before 1992.
The problem was reported to BUGTRAQ and has now made the rounds at many software security sites.
MITRE CVE: CAN-2005-0892 (under review)
Initially I didn't think it could be exploited, but I didn't realize
just how easy it is to foil
free() in some systems, to the
point of being able to convince it to overwrite any address with as much
as four bytes of user-supplied data, and this particular overflow was
directly in line with another buffer and an imminent
A limited exploit has also been released -- it only affects platforms
using the Doug Lea Malloc, such as most GNU/Linux platforms,
and it only works as released on i386 systems, and only on systems with
executable heaps. In theory it's possible to exploit the PHK
malloc() used in *BSD systems, but that's a _much_ more
complex problem for the attacker to solve. (Apparently the SysV
malloc(), i.e. the one in Solaris and modern IRIX, should
also be exploitable, perhaps even as easily as implementations based on
The Smail-220.127.116.11 release includes official fixes. The most important
part of the fix is to NUL-terminate the string created from the first
part of the route, so even adding this line after
strncpy() call on line 223 of src/addr.c should
p[(ap - address)] = '\0';
The official fix not only terminates the unterminated buffer as above, but also adds further protection against allowing arbitrary binary data from remote clients -- only ASCII, as per RFC 821, will be accepted in SMTP commands from now on!
Note the claim about signal handler bugs this Sean fellow also makes in
his initial advisory are not very tangible. Yes there's a slim chance
the SIGINT signal handler could call
malloc(), though only
if it's the very first time
write_log() is called. Note
also that this could only ever be vulnerable to attack by already
authorized local users. An exploit would have to rely on interrupting a
malloc() call in such a way that a re-entrant
call would cause enough damage that the return address of the
write_log() call could be corrupted (as the next call is
exit()) -- and then there's the issue of getting the
desired new return address into the right place at the right time.
In any case the 18.104.22.168 release also pre-allocates the
write_log() string so that it is always long enough to hold
any message that might be generated by any signal handler. That should
calm down the MITRE folks a bit.
MITRE CVE: CAN-2005-0893 (under review)
Note that Smail-3 an easily be linked against any other available
malloc(3) compatible library and has regularly been tested
with debugging libraries such as the likes of ElectricFence, vmalloc,
and dmalloc. This of course won't always prevent the
calls smail makes from using the system
malloc(), even when
smail is static-linked, but it's a good first start.
Does anyone happen to have an allocator handy that doesn't use pointers mixed up within the same area where the buffers live?
Smail-3 was written as a Sendmail replacement for normal people and as such has a much simpler configuration interface insted of the finite state machine that drives Sendmail. In fact the most recent versions should work out of the box with no post-compilation configuration necessary on most leaf node sites.
The major version number of Smail is "3" because it came after Smail-2.
The first mailer called "Smail" was a very simple UUCP mailer written a
rather long time ago by Chris Seiwald when he was at AT&T in order
to do automatic UUCP routing using
pathalias and the UUCP
Map Project database. Smail-2, by Mark Horton and Larry Auton, replaced
that first version of Smail. Smail-3's authors liked the simplicity of
Smail-2 and their idea was to write a new mailer for Smail-2 users and
others who did not want to have to use sendmail, i.e. to bring new
gateway and Internet SMTP capability to Smail users without sacrificing
the simplicity they were accustomed to. Other than that Smail-2 and
Smail-3 are really linked only in name.
Smail-1 was probably written just about the same time as sendmail, or maybe just slightly before, but I'm not sure (sendmail is first copyright in 1983). The earliest date still recorded in the Smail-2 sources is 1985, and I worked on Smail-2.7 as late as 1994 after early versions of Smail-3 were already in fairly widespread use. The current CVS repository was started with an import of the 3.1.28 sources on 1993/12/08 and the first relase not done at least partly by the original authors was 3.1.29 on 1994/11/01. I started making more major contributions to Smail in 1995 and was the primary maintainer by early 1996.
Most other currently used SMTP-capable mailers, including zmailer, exim, qmail, postfix, and so on were written long after sendmail was first released and most were also written to address the many shortcomings of sendmail. Exim was in fact modeled after Smail-3 and could in some senses be considered to be a full rewrite, though it has since diverged significantly from Smail-3 in its design and philosophy.
And many MANY more who reported bugs, helped with testing, provided suggestions and ideas, etc.