On February 9th, 2016, Google announced that emails received via an insecure connection would be marked with an open red padlock, indicating that the contents of the email could be viewed while in transit. Given the attention that online security is getting these days, it’s refreshing to see that SMTP connections are finally in someone’s crosshairs.
Securing Email Systems
On the server administration side, email-related encryption comes into play on 3 fronts:
- Reading email (POP/IMAP connections)
- Receiving email (inbound SMTP connections)
- Sending email (outbound SMTP connections)
Regardless of your mail system’s native support for encrypted connections, items #1 and #2 can be worked around with other packages; I’ve used stunnel and courier to secure POP/IMAP connections, and nginx’s reverse mail proxy to secure inbound SMTP connections.
However, fixing item #3 without native support for TLS is trickier – outbound connections can’t be proxied in the same way. Using a persistent secure tunnel to an external relay is possible, but that external relay would likely be a paid service like Mandrill or Sendgrid, introducing an additional layer of complexity into the architecture.
Fortunately a TLS patch for Qmail exists, so to remove the red padlock from outbound emails from my systems, I’ve added the patch to my netqmail package for Ubuntu. It’s been running in production on multiple servers for the last two months without problems, so I’m relatively confident that I’ve correctly translated the patch.
If you choose to install or upgrade to this version of netqmail, please note that there are a couple caveats. I hope to find ways to fix them in the installation, but until then, here’s what you need to know:
1. TLS is *not* enabled by default – you need to generate a private key and certificate
openssl req -newkey rsa:1024 -x509 -nodes -days 7300 -out servercert.pem -keyout servercert.pem
ln -s servercert.pem clientcert.pem
The OpenSSL command will prompt you for information about your system to generate your certificate. The most important item is the Common Name (CN) field: it should match the MX record that points to the server. As long as the certificate doesn’t use weak/outdated encryption, Google (and other providers) don’t seem to be penalizing self-signed certificates.
The server certificate is also symlinked to the client certificate file; the same certificate can be used to secure both inbound and outbound connections.
2. dh2048.pem and rsa2048.pem are not immediately generated
Diffie-Hellman parameters are necessary for the server side of the connection, and can either be cached or are generated on the fly when new connections are initiated. Generation of these parameters is expensive, however, and can take a long time, so normally they’re regenerated daily by a cron job. This cron job is included in the netqmail package.
Given that parameter generation takes an indeterminate and potentially long time, it’s not performed as part of the installation. Therefore, prior to these parameters being generated and cached for the first time (within 24 hours of installation), server connections may take (much) longer than normal. After installation, I recommend immediately generating these parameters:
The Launchpad repository now upgrades the qmail-run package as well; the overhead of TLS support increases the memory required for the SMTP server. Hence, the tcpserver softlimit has been increased.
Got all that? Great! Your Ubuntu Qmail installation is now capable of sending and receiving email securely. There are additional configuration directives that impact qmail-smtpd and qmail-remote, but the defaults should be fine for most installations.
Using Better Qmail on Ubuntu? I’d like to hear about your experiences with it in the comments.