Protect your users’ in-transit email from eavesdroppers the Qmail way.
If
you
want to protect your users’ email with strong encryption, you might be wary of using a package with a less-than-illustrious security track record, such as Sendmail [Hack #55]. Another option is to use Qmail (http://cr.yp.to/qmail.html).
Setting up Qmail to support TLS can seem daunting at first, because there is no “official” patch for doing so; all enhancements to Qmail are like this. This hack uses a patch that integrates SMTP AUTH and TLS, so that you can also require that your users authenticate with your SMTP server before it will allow them to relay mail through it.
First, download the patch (http://shupp.org/smtp-auth-tls/), change to the directory containing the Qmail source code, and apply the patch:
#cd /usr/local/src/netqmail-1.05/netqmail-1.05#patch -p0 < ../../netqmail-1.05-tls-smtpauth-20060105.patch
Then, check to see if the patch applied cleanly:
# find . -name \*.rej
After you’ve verified that the patch was applied correctly, stop Qmail by running the following commands:
#svc -d /service/qmail-smtpd /service/qmail-smtpd/log#svc -d /service/qmail-send /service/qmail-send/log
Now, run make setup check to reinstall it. If you need to generate x.509 certificates, you can run make -f Makefile-cert cert. This will prompt you for information to create a certificate/key pair that will be used to encrypt traffic between your Qmail server and other SMTP servers, as well as between it and your users’ mail clients.
Once the certificate and key have been generated, they’ll be placed in /var/qmail/control/servercert.pem (with a symbolic link to /var/qmail/control/clientcert.pem). Of course, you could just skip this step and make a symbolic link to those locations from a certificate/key pair that you’ve already created [Hack #69]. Once you’ve gotten your certificates squared away, run make tmprsadh to generate the Diffie-Hellman key exchange parameters.
Now, you’re ready to restart Qmail:
#svc -u /service/qmail-send /service/qmail-send/log#svc -u /service/qmail-smtpd /service/qmail-smtpd/log
If you telnet to port 25 of your server and issue an EHLO command, you should now see that the server supports STARTTLS and SMTP AUTH:
$telnet mail.example.com 25Trying 192.168.0.2... Connected to mail.example.com. Escape character is '^]'. 220 mail.example.com ESMTPEHLO250-freebsd5-vm1.nnc 250-STARTTLS 250-PIPELINING 250-8BITMIME 250-SIZE 0 250 AUTH LOGIN PLAIN CRAM-MD5
You’re almost done. All you need is a way to let Qmail check your users’ passwords for it to authenticate them. This is done with the
checkpassword program (http://cr.yp.to/checkpwd.html). If you’re using Qmail as a POP3 server, you probably already have it installed properly, so you’re done. If you don’t, download and unpack the source tarball for checkpassword, change to the directory that was extracted (e.g., checkpassword-0.90), and run make setup check as root.
After it’s installed, you’ll need to make checkpassword SUID, so it can verify user passwords:
# chmod 4711 /bin/checkpassword
You’re now set on the server side. Your users can enjoy encrypted email between their clients and your server. In addition, you can allow your users to send email from wherever they are, since you don’t have to restrict relaying based on hostnames any longer.
However, keep in mind that email will be encrypted only between the clients, your server, and any destination servers that support TLS. If a recipient’s server doesn’t support TLS, the message will be sent in the clear at some point. For true end-to-end encryption, you can use GnuPG [Hacks #42 and #43].