sSMTP: A simple alternative to Sendmail

Linux distributions have relied on the venerable Sendmail package since the early days of Slackware. But Sendmail’s rich mail server features aren’t an ideal solution for the typical desktop user whose primary mail support is delivered through a remote ISP. That’s the perfect place for a simpler solution: sSMTP.

Many years ago, before the Internet standardized on Simple Mail Transfer Protocol (SMTP), applications known as mail transfer agents (MTA) were designed to help process email and determine the best route for message delivery. One of the earliest MTAs, Sendmail, became extremely popular for dealing with the delivery of email across multiple networks. It was the only viable open source mechanism for delivering email at the time Linux was introduced to the world, so it became the default MTA provided on many Linux distributions.

There has always been a division of labor for email processing. MTAs handle delivery of email and mail user agents (MUA) such as GNOME’s Evolution, KDE’s KMail, and Mozilla Thunderbird let users create and manage messages. MUAs have only a very basic concept of how to deliver mail. They don’t need to know how to send a message to its intended recipient; they know only about delivering mail to a specific generally server-based MTA, which is then responsible for routing email to the ultimate recipient.

If you run cron jobs or some automated system that sends you alerts via email, the default method the system uses for sending the message is Sendmail, because it is the default MTA for the built-in Linux mail command (typically /bin/mail). This means you not only have to configure your mail reader to send email to your ISP, but you also need to configure Sendmail to do the same thing.

Unfortunately, Sendmail configuration is a mass of twisty passages that even the most experienced user avoids if at all possible. That means it is not the best tool for the typical desktop user.

Two popular Sendmail MTA alternatives, QMail and Postfix, started off simple, but have become complex systems on their own, with capabilities far beyond the needs of a typical desktop user who seeks to simply route email from his machine to his ISP. Alternatively, you could choose a tool other than /bin/mail to send email through direct use of SMTP, such as elm or pine, but these are full MUA clients that provide lots of options that are overkill for addressing the primary problem of mail delivery to an ISP.

The simplified solution: sSMTP

Instead of finding a complicated replacement for mail, you can replace the complicated Sendmail with a simple alternative: sSMTP. sSMTP simplifies configuring your SMTP options with a small configuration file that allows you to specify items like the name of the remote SMTP server, your authorization (username and password), and the domain for your outbound email in much the way you configure your mail reader.

You can install sSMTP through your distribution’s package manager, or build and install it from source. In the latter case, unpack the source, change into the source directory, and run the command ./configure --prefix=/usr/local/ssmtp --enable-ssl --enable-md5auth. Enabling SSL and MD5Auth allows you to communicate with an ISP that requires SMTP login. You can also enable IPv6 support if you need it; see --help for details.

After the configuration is complete, build and install the package using the normal make and sudo make install commands. When you run the install command you will be prompted for a few items. Follow the displayed instructions. Once installation completes you should find a directory called /usr/local/ssmtp with the sSMTP binary under the sbin subdirectory, and the configuration file under the etc/ssmtp subdirectory.

Now you can stop Sendmail and replace it with sSMTP. To stop Sendmail under Linux distributions that use the System V init scripts (and most distributions these days do) you can try the service command:

  sudo service sendmail stop
  sudo chkconfig --levels 2345 sendmail off

The first command stops the currently running instance of Sendmail, and the second prevents it from starting again on reboots. If your version of Linux does not use the SysVInit package you may need to kill the sendmail process manually with a command like sudo killall sendmail.

To replace Sendmail you can simply copy it to another file, then create a symbolic link from sSMTP to sendmail:

  sudo mv /usr/sbin/sendmail /usr/sbin/sendmail.orig
  sudo ln -s /usr/local/ssmtp/sbin/ssmtp /usr/sbin/sendmail

The first command moves the original sendmail out of the way, while the second makes sSMTP the program that gets run when any system command calls sendmail. With this approach, if you run into problems using sSMTP, just remove the symbolic link and move the sendmail copy back to its original name.

Configuration

The configuration file for sSMTP, based on the --prefix option we used with the configure command while building from the source code, is /usr/local/ssmtp/etc/ssmtp/ssmtp.conf. This file has only four common options, plus some hidden options for authentication.

After a sample build, sSMTP created the following configuration file for me (lines starting with a # symbol are comments):

  # /etc/ssmtp.conf -- a config file for sSMTP sendmail.
  #
  # The person who gets all mail for userids 
Change the root= value to an email address that will receive all system-generated email, such as output from cron jobs that encounter errors or log file analysis. I changed this line to my personal email address.
mailhub= defines the SMTP server to which email should be sent. Set this line to the host you specify in your mail reader for the SMTP server.
hostname= is the name of the mail host that you'd like recipients of your email to see it. Since I want responses to my email to be sent to back to my ISP domain so I can use my mail reader to retrieve it, I set this line to the ISP domain. This is the domain part of all outbound messages; all users on your system will appear to be coming from this domain.
You can use rewriteDomain= to spoof who you say you are. Since I'm already spoofing the server address with the hostname line, I leave this line commented out.
The initial configuration does not include information on how to log in to SMTP servers that require authentication. This information is the same information you must provide in your mail reader in order for it to send email through your ISP. To specify this information, you can add the following lines: 
  AuthUser=your username
  AuthPass=your password
  AuthMethod=CRAM-MD5

With this configuration, every time my system sends mail using /bin/mail, sendmail gets called, which is actually sSMTP. sSMTP uses the authentication I provided in the configuration file to log in to my ISP's SMTP server and deliver my outgoing email.
Caveats
Replacing Sendmail with sSMTP works well for desktop PCs that have only a single user configured. If you have multiple users, you may not want to use sSMTP, since by default all email sent via the mail command will look like it comes from a single user. An additional configuration file, revaliases, allows you to map a local user to a specific From: address on outbound mail and to route that mail through a specific mailhub. Still, there is no way to configure different logins on different mailhubs that use different different authentication credentials. With sSMTP, your outbound mail can only have one remote MTA to which it can connect.
Also, in order for any user on your system to use sSMTP, they will need to have read permissions on the ssmtp.conf file. Placing your ISP login information in a configuration file that is world-readable allows anyone who uses your system to see your email authentication information. This is another reason why use of sSMTP is appropriate only for home users who are the sole users of that system. You can fix this problem through normal user and group permissions and by running sSMTP as a setuid program, but not if you want to make things as simple as possible, as we set out to do.
While sSMTP is a replacement for Sendmail, it is not a complete replacement. One important distinction is that it is not intended to receive mail, as Sendmail does. You need to use a mail reader to retrieve and read email from your ISP.
sSMTP also does not manage mail queues, so it sends outbound email immediately. Although the man page for sSMTP shows support for all the same command-line options that Sendmail supports, sSMTP ignores most of those options.
Finally, the sSMTP implementation enforces a limit on the size of outbound message headers. Try not to write long subject lines or include long lists of recipients. If you need to send something to a large list of recipients, set up an alias instead of manually listing all the recipients on the command line.
sSMTP is exactly as advertised: simple. It requires only minimal effort to set up and little to no long-term maintenance. But it isn't appropriate for all users. Its greatest value is to the non-technical home user with only one user configured on a machine. To those users, sSMTP can be an easy way to improve messaging management.