Simplify email with Smail

A mail transport agent (MTA) provides the “plumbing” for your email system by taking mail from a client application such as Evolution or Mozilla Thunderbird and routing it to the correct location on the right machine. There are plenty of good MTAs, such as Postfix, Sendmail, and qmail, but these popular mail servers require a large amount of configuration, and may be overkill for users who merely want to set up an MTA to test a Web development project or need to move mail around locally. Smail is a better alternative for these scenarios because it generally requires no configuration, and its memory footprint is less than the more fully featured MTAs.

Smail is almost completely compatible with the Sendmail in terms of command-line usage, so if you know how to use Sendmail, you won’t need to read much documentation to get running with Smail. Its configuration files are simpler than Sendmail’s, and Smail can handle a large number of users without needing a huge amount of system resources. The venerable application has been around since 1994; it was released at around the same time as Sendmail. According to the developer, Smail is relatively secure, and it has been the subject of only one security advisory since 1994 until recently. A heap-based buffer overflow problem was discovered recently, but it is only an issue on i386 systems with executable heaps. There’s also a signal-handling vulnerability for which a patch is available on the project Web site; it consists of pasting a line of code into the src/addr.c file. The issue will be fixed in the source in the upcoming 3.3 release.

Because setup and configuration is so easy, Smail is perfect for situations where you don’t want to put a lot of effort into building an email infrastructure and don’t need complicated features. For instance, it’s great for use on systems where users run applications that make use of email notifications. I use Smail in conjunction with testing a Ruby on Rails application that sends an email message to users when they register for a new account. When you match up Smail with a full mail store that supports POP or IMAP, Smail becomes a complete mail server solution.

Setting up and configuring Smail

Most distributions include Smail in their repositories, so installing it should be easy. On Debian and Debian-based distributions, a command like apt-get install smail should do the trick. If you are using a different distribution, or if you can’t find the package in your repository, you can download the source code from the developer’s site and compile it by hand.

On Debian-based systems, the package manager will automatically invoke Smail’s configuration utility. On other platforms, you can start the utility from the CLI with the smailconfig command.

The configuration utility asks a series of questions, then automatically configures Smail for you without your having to edit configuration files by hand. When you execute smailconfig, a series of options will appear in the console. For most users, the best option is the first one, to set Smail up as an Internet site. This will allow users to send and receive mail from the Internet using SMTP or using a smart host, which is an email relay server. The second option also uses a smart host, but it does so with UUCP (Unix to Unix Copy) instead of with SMTP. The third option configures Smail for use with a central switch; no mail is sent or delivered at the user’s machine but is forwarded to a different server, where it is processed. The last option is a local-only configuration: mail is delivered only for users on the local machine.

Smail is ideal for systems where virtual users aren’t required; you don’t need to authorize users to transport mail. Users can overwrite the default settings created by the configuration wizard easily by opening /etc/sendmail/config in a text editor. From there, users can edit hostnames, queue settings, and SMTP flags (that is, the style of the response from the server), and adjust allowed connections. The settings in the text file take precedence over the information set with the configuration wizard, but the configuration file will be reset if the user executes the wizard again. Doing that can be helpful if a user breaks Smail by adjusting a setting and didn’t back up his configuration file.

After Smail configuration is finished, it’s pretty easy to use the server to send mail. At least on Debian-based systems, Smail is set to start as a daemon on system boot. You can also set Smail to launch with your system through the GNOME and KDE settings panels, or with a command-line utility. To send a message, you can employ a mail user agent (MUA) such as alpine, or you can invoke Smail with the smail user@host.com command. If you prefer to use a graphical application to manage mail, you can use Balsa, which has support for local mailboxes. In that case, after composing a message, you specify a full stop (a period on a line by itself) to alert Smail to the end of the message. You can also use specific headers that are recognized by email servers to add detail to your messages, such as writing Subject: Smail Review to add a subject field viewable in other mail agents.

You can use Smail with an IMAP store that will receive, collect, and categorize messages. My personal favorite IMAP server is Cyrus IMAP, which should be available in most distribution repositories. Cyrus can be relatively difficult to set up, so users should be sure to follow the directions on the project Web site. In order to get it working with Smail, you can follow the configuration settings for Sendmail.

Smail’s automated configuration and low resource utilization make it a good alternative for systems that require a simple mail server. You can easily extend Smail to include POP and IMAP functionality, most easily by combining it with Cyrus IMAP. Make it even more accessible with a Web interface such as SquirrelMail, and your users can have a mail system equal to that of most ISPs’.