The Smail-3 Mail Transfer Agent

General Information

One of the longest-lived freeware projects that I have worked on has been the maintenance of Smail-3.

Description

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.

Features

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.

Release Information

You can fetch the latest code itself by FTP from the master site at:

    ftp://ftp.planix.com/pub/Smail/smail-BETA.tar.gz

A pkgsrc-compatible set of modules which matches the latest release is also available here:

    ftp://ftp.planix.com/pub/Smail/smail-pkgsrc.shar

You can sometimes find un-released previews here (if you unpack the pkgsrc shar file it will reference the latest preview automatically):

    ftp://ftp.planix.com/pub/Smail/smail-*-Pre-*.tar.gz
    ftp://ftp.planix.com/pub/local/smail-pkgsrc.shar

Freecode Reference

Smail is listed on freecode.com at http://freecode.com/projects/smail/

Other References

The Free Software Foundation's GNU Project has a very minimal little page describing Smail here:

    http://www.gnu.org/software/smail/smail.html

and another entry in their software directory here:

    http://directory.fsf.org/wiki/Smail

There is a reference to Smail in the dmoz open directory project:

    http://dmoz.org/

Future Plans

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.

Free Support and Mailing Lists

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 smail3-users-request@athabascau.ca

I also actively support those of our customers who are using Smail, providing them with both programming and support services.

Important Security-related Announcement for Smail-3.2.0.120 and older.

Note: This problem was fixed very early in the release cycle for Smail-3.2.0.121.

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.

	http://www.securityfocus.com/archive/1/394286
	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 free() call.

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 Doug Lea's.)

	http://www.securityfocus.com/archive/1/394413

The Smail-3.2.0.121 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 the strncpy() call on line 223 of src/addr.c should suffice:

	    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 [2]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 very early 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 3.2.0.121 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 libc 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?

History

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.

People

Current Maintainer:
Original Developers:
Some of the contributors to Smail:

And many MANY more who reported bugs, helped with testing, provided suggestions and ideas, etc.


For further information about the Smail project in particular, or to comment on this particular web page, please contact me at this address: woods-smail@planix.com

Last updated on %E% at %U% (version %I%).
Copyright © 2001 - Greg A. Woods. All rights Reserved
Last modified: