In my previous article, Use getmail to get e-mail simply and securely, I mentioned two opposing approaches to handling e-mail. On one side is the use of monolithic, fancy, massively multi-function (“feature rich”), GUI-fied mail clients like Microsoft’s “personal information manager,” Outlook. On the other is the computer user like me, who prefers daily e-mail dealings to be quick, simple, and devoid of distractions. We tend to use a collection of small, separate tools to fulfill each of the critical functions of dealing with e-mail — one for retrieving incoming mail from the server; another for reading, managing, and composing e-mail; one more for sending it.

I have previously covered using mutt with GnuPG, thus covering both the reading/managing/composing and privacy functionalities in a single article, and getmail in my last article for retrieving e-mail from a POP server. This time, I’ll address sending e-mail with a simple SMTP client called sSMTP on Unix and Linux systems — specifically, how to use it with a secure encrypted connection to your SMTP server.

Secure SMTP server authentication:

Not only is sSMTP a simple, straightforward tool for handling outgoing mail, but it is a secure tool as well — when used properly. An important component of e-mail security, in addition to use of digital signatures and e-mail encryption, is protecting your authentication exchanges for connections to SMTP and incoming mail servers. Whenever you connect to any kind of mail server, you should be using a username and password to authenticate yourself:

  1. On a POP or IMAP server, authentication is used to ensure that only the “owner” of a given e-mail account can access the e-mails intended for that person.
  2. On an SMTP server, authentication is used to ensure that unauthorized people are not sending e-mail through that server. Among other important reasons for this, there’s the concern that spammers might use an SMTP server to spam others, and ultimately get the server blacklisted by spam filtering services.

That authentication process needs to be encrypted. Strong encryption for your e-mail account authentication keeps malicious security crackers from capturing your username and password by eavesdropping on network traffic. When people can acquire your usernames and passwords, the privacy and resource protection that authentication is meant to provide is ineffective, because others can then invade your privacy and misuse your resources.

I use TLS encryption to protect my mail server sessions from eavesdropping malicious security crackers. TLS is, as I mentioned in an article about basic Web security, effectively the next version of SSL. The sSMTP tool provides functionality for using TLS/SSL to secure your connections with your SMTP server.

Configuring sSMTP:

Your SMTP server has to support encrypted sessions if you wish to establish a secure connection with it. Check with your ISP, hosting provider, network administrator, or whoever manages the server to see if encrypted sessions are supported. If the SMTP server does not support some form of encrypted authentication, get a different service provider if at all possible. As I pointed out in the article Basic e-mail security tips, it’s always a good idea to make sure your e-mail authentication process is encrypted.

I am providing my own sSMTP configuration file — with syntax modifications to protect my privacy, of course — called ssmtp.conf, to illustrate how you might use sSMTP to secure connections with your SMTP server when sending e-mail. The file is located at /usr/local/etc/ssmtp/ssmtp.conf on FreeBSD systems by default, and /etc/ssmtp/ssmtp.conf on Debian GNU/Linux. Other systems may vary.

The contents of the file on my laptop, modified as indicated above, are:






I’ll explain each line in the file in turn:

  • This identifies what user account receives all mail for userid under 1000 on the local system. That basically means system accounts, such as the root user account. In other words, if your computer is trying to send your root account an e-mail message, it will send it to whatever e-mail address you specify her. This should normally be your primary e-mail account — probably the account for which you’re configuring sSMTP to send e-mails.
  • AuthUser=username: The username indicated here should be the username used to log into the remote SMTP server. In many cases, this is the part of the e-mail address that comes before the @ sign in your e-mail address. In some cases, it may be the entire e-mail address, possibly with the @ replaced by a plus sign. Using the example above, this means it the username entry might be, depending on the SMTP server configuration.
  • AuthPass=password: When authenticating, this is the password used with the username above. Because my e-mail password is stored in the file, I make sure the ssmtp.conf file permissions are set to 640 using the chmod command. This ensures that the ssmtp and system administrator accounts can access the file as needed (both to make sure the ssmtp process works properly and that I can edit the file as root when needed), but no unprivileged accounts have access to the contents of the file. For this to work, you will also need to ensure that you create an ssmtp user (with a command like pw useradd ssmtp -g nogroup -h - -s /sbin/nologin -d /nonexistent -c "sSMTP pseudo-user") and set ownership of ssmtp.conf to that user (with a command like chown ssmtp ssmtp.conf).
  • Set the mailhub option to the fully qualified hostname for the SMTP server you will be using, so that sSMTP knows where to send outgoing e-mails. This option may actually take the form, which sets the port number to use when contacting the SMTP server to 465. This allows unencrypted connections to use 25 (the default port number for SMTP traffic), and 465 is the standard alternate port number for TLS- and SSL-protected SMTP connections.
  • This tells sSMTP that your mail headers need to be edited to say that the domain name you use for your e-mail address will be listed as the source of your e-mail address. Failing to rewrite the source domain name in this manner may cause problems at the receiving end when your e-mail address arrives at its intended destination.
  • hostname=hostname.domain: The hostname indicated here is the hostname of the computer you are using to compose and send e-mails. The .domain part may or may not be present. On Unix and Linux systems, you can find the hostname for your computer by entering the command hostname at the shell prompt.
  • FromLineOverride=YES: The From: header in an e-mail handled by sSMTP can be overwritten at this point. Setting this to YES just uses the From: value provided by the program that sent the e-mail to sSMTP to be forwarded to the SMTP server in the first place. In my case, since I use mutt as my mail user agent, this means that setting FromLineOverride=YES will cause sSMTP to use whatever From: header line mutt provides.
  • UseTLS=YES: At last, we’ve struck gold. This is the configuration line that tells sSMTP to encrypt its connection to the SMTP server, protecting your authentication username and password as well as the rest of the session.

For more information about sSMTP configuration, the program’s manpage (which you can access with the command man ssmtp) should provide more useful information, as can a Google search for ssmtp.conf. Most of the time, when you install sSMTP using the native software management system of a major free Unix-like system such as a BSD Unix or Linux-based system, an example configuration file will be provided with comment lines explaining the available options.

Securing the other tools:

In addition to sSMTP, of course, you should also secure the other e-mail tools you use. You can use GnuPG and Mutt to encrypt e-mail, and tools for handling incoming mail like getmail and fetchmail can be configured to use TLS/SSL encryption as well.