Protect your users’ in-transit email from eavesdroppers.
If you have set up encrypted POP and IMAP services [Hack #47], your users’ incoming email is protected from others once it reaches your servers, but what about their outgoing email? You can protect outgoing email quickly and easily by setting up your MTA to use Transport Layer Security (TLS) encryption. Virtually all modern email clients support TLS—enable it by simply checking a box in the email account preferences.
If you’re using Sendmail, you can check to see if it has TLS support compiled-in by running this command:
$ sendmail -bt -d0.1
This will print out the options that your sendmail binary was compiled with. If you see a line that says STARTTLS, then all you need to do is supply some additional configuration information to get TLS support working. However, if you don’t see this line, you’ll need to recompile sendmail.
Before recompiling sendmail, you will need to go into the directory containing sendmail’s source code and add the following lines to devtools/Site/site.config.m4:
APPENDDEF(`conf_sendmail_LIBS’, `-lssl -lcrypto’)
If this file doesn’t exist, simply create it. The build process will automatically include the file once you create it. The first line in the example will cause TLS support to be compiled into the sendmail binary, and the second line will link the binary with libssl.so and libcrypto.so.
After adding these lines, you can recompile and reinstall sendmail by running this command:
# ./Build -c && ./Build install
After you’ve done this, you will need to create a certificate and key pair to use with sendmail [Hack #45] . Then you’ll need to reconfigure sendmail to use the certificate and key that you created. You can do this by editing the file your sendmail.cf file is generated from, which is usually /etc/mail/sendmail.mc. Once you’ve located the file, add lines, similar to the following, that point to your Certificate Authority’s certificate as well as the certificate and key you generated earlier:
The first line tells sendmail where your Certificate Authority is located, and the second one tells it where to find the CA certificate itself. The next two lines tell sendmail which certificate and key to use when it is acting as a server (i.e., accepting mail from a MUA or another mail server). The last two lines tell sendmail which certificate and key to use when it is acting as a client (i.e., relaying mail to another mail server). Usually you can then rebuild your sendmail.cf by typing make sendmail.cf while inside the /etc/mail directory. Now kill sendmail and then restart it.
After you’ve restarted sendmail, you can check whether TLS is set up correctly by connecting to it:
# telnet localhost smtp
Connected to localhost.
Escape character is ‘^]’.
220 mail.example.com ESMTP Sendmail 8.12.9/8.12.9; Sun, 11 Jan 2004 12:07:43 -0800 (PST)
250-mail.example.com Hello IDENT:6l4ZhaGP3Qczqknqm/KdTFGsrBe2SCYC@localhost
[127.0.0.1], pleased to meet you
250-AUTH DIGEST-MD5 CRAM-MD5
221 2.0.0 mail.example.com closing connection
Connection closed by foreign host.
When sendmail relays mail to another TLS-enabled mail server, your mail will be encrypted. Now all you need to do is configure your mail client to use TLS when connecting to your mail server, and your users’ email will be protected all the way to the MTA.
While there isn’t enough room in this hack to cover every MTA available, nearly all support some variant of TLS. If you are running Exim (http://www.exim.org) or Courier (http://www.courier-mta.org), you can build TLS support straight out of the box. Postfix (http://www.postfix.org) has TLS support and is designed to be used in conjunction with Cyrus-SASL (see the HOWTO at http://postfix.state-of-mind.de/patrick.koetter/smtpauth/). Qmail has an RFC 2487 (TLS) patch available at http://inoa.net/qmail-tls/. With TLS support in virtually all MTAs and email clients, there is no longer any good reason to send email “in the clear.”