After the recent revelations that makes WEP security paperthin, coupled with my own increased use of Wi-Fi in public spaces without any encryption, I determined to see how difficult it would be to enable SSL support in my mail server.

SSL would encrypt all communication between the mail client and mail server, rendering it impervious to cracking - or at least much much much more impervious than sending your mail password in clear text (which is what happens in an open wireless network or open Internet network).

I'm not really a Unix system administrator; I learned how to run a Unix box (originally SunOS 4.1.3 back in 1994) by default to start a Web company. Nonetheless, even though I cannot write C programming code, I can compile software and configure Linux boxes with relative ease. What follows isn't for the faint of heart, but hand it to your system admin, if it's too far beyond your interest.

I knew that both Eudora and Outlook had enabled client-side SSL support in recent versions. I knew that Exchange (which I don't use) and sendmail (which I do) had the server-side components.

SSL uses a relatively clever system to encrypt messages without huge cryptographic overhead. Using a third-party certificate authority to keep both parties in a transaction honest, the two parties in SSL first exchange a key encrypted using public-key encryption. The key they exchange is then used for subsequent data interchanges. This allows a strong encryption system to be initiated through a secure key transfer.

I had the latest version of sendmail, 8.11.5, and I found a wonderful and straightforward page on how to compile and configure sendmail with SSL support. This page told me which files I needed, how to install and configure them, and how to create my own mini-certificate authority (CA). This last step allows an installation to not have to buy a certificate from VeriSign, which is perfectly fine when you're working with your own customers, employees, or colleagues, so no trust issue is at stake that a third party needs to be involved with.

It turns out that the steps involved in getting sendmail configured are trivial. I then proceded to the mail retrieval side: qpopper from Qualcomm, a free and highly configurable POP server. Again, it turns out that this is a breeze, but not as well documented.

You compile qpopper (if you've followed all the recommendations of the sendmail compilation) like this:

./configure --with-openssl=/usr/local/ssl

This points to the OpenSSL libraries and binaries. Now do the make and make install. Make sure that your inetd.conf or xinetd configuration files point to this new /usr/local/sbin/qpopper file, or that you put qpopper in the expected place.

Now you need to change the invocation of qpopper in inetd.conf or xinetd configuration:

qpopper -s -f /etc/pop.options

Make a new file called pop.options in etc, and put these lines in it:

set tls-private-key-file='/etc/mail/certs/key.pem'
set tls-server-cert-file='/etc/mail/certs/cert.pem'
set tls-support=stls

Reload inetd or xinetd, depending on Unix/Linux version. You should now be all set.

Remarkably, it does work - but only for POP. An obvious difference of opinion between the major client developers (Outlook and Eudora) and the sendmail team have led to an incompatibility in current versions of all interacting products. Notes for the next sendmail release, 8.12, indicate that the software will offer a configuration switch to fix this problem (which requires the client to send certain kinds of certificate information which Eudora and Outlook don't).

To set up Eudora with POP - which is the more important of the two, given that POP would allow your passwords to be sniffed - I went into Eudora 5.1 for Macintosh, selected SSL from Settings, and changed SSL for POP to Required. I tried to connect, and my Mac wisely warned me that the certificate authority for my mailserver was unknown; I accepted this, saved it, make another request - and now I'm secured for retrieval.