Postfix/TLS - Initial Motivation

This introduction shall point out the motivation, why I spend my time writing this TLS extension for postfix.

Roaming users problem

It quite often happens that my users want to access their mailboxes and to send emails from hosts outside our network. The main reasons are the access from home via Internet service providers (ISP) or from abroad during business trips (in our case typically to other universities around the world). Sending and accessing leads to two loosely coupled problems.

UCE control

One problem is sending emails, because from abroad it is seldom possible to predict the sending hostname we will have and when using an ISP the assigned hostname is typically random. As we of course must have UCE control in effect, I either must open up relaying complete ISP domains on my users request (Arrgghh!) or must introduce an authentication beside the hostname or IP address.

Passwords and insecure networks

This directly leads to the second problem. Recent versions of Netscape do offer password based authentication. This solves the UCE problem but introduces another one, which I consider far more severe: The users have to send a password in plain text over the network. Of course I could solve this problem by issuing special passwords just for this reasons, but some of my users don't have a clue of what is going on between the keyboard and the screen, so they would happily try their real password.

The same problem of course also applies to the POP and IMAP services. I tackled them first, because they are typically attacked by port scanners, so I closed them down by tcpwrappers (Hi Wietse!) to only allow my local hosts to access them.

Encryption via SSL

The solution to the plain text password problem was easily found with the use of SSL. You just tunnel the POP or IMAP connection through SSL, using either SSLwrap [SSLWRAP] or stunnel [STUNNEL].

Netscape supports IMAP with SSL tunneling since version 4, I have one user with Outlook Express, who uses POP3 with SSL tunneling, so this solves the plain text password problem by encryption.

Netscape 4.5

Starting with Netscape 4.5, also sending with SSL encryption is supported. As Netscape also supports client certificates, this seemed to be an easy solution for the UCE control problem. So I happily added an "smtps" service with SSL wrapper and client certificate verification. Unfortunately it didn't work and the connection just hung! After some digging around I found out, that Netscape 4.5 seems to realize the protocol described in RFC 2487 [IMC].

RFC 2487 - SMTP Service Extension for Secure SMTP over TLS

RFC 2487 describes how to include TLS (the successor of SSL) into the normal Extended SMTP protocol. During the normal EHLO start negotiation the server offers the STARTTLS option to the client, which then issues the STARTTLS command. After the server accepts the command (220), the normal SSL handshake will start.

Unfortunately it is impossible to handle this situation with a normal tunneling software, as they are not prepared to do clear text negotiation before running SSL and don't have the slightest idea on the SMTP protocol. Therefore the way to go was to extend a given mail server software. The first candidate was sendmail-8.9.3, as I was a long term sendmail user. After digging around some I came to the conclusion, that even though possible, the source code was quite difficult to understand and adding the necessary configuration options didn't look inviting.

Postfix

At this point (February 1999) I checked other mail servers and was immedideately fascinated by postfix source. It was very good to read and understand, so I decided that if I would take the time, then postfix would be the way to go.

I then started to first change our site to postfix. It took some hours to do this, because our mail system is running on a common network I administrate for several chairs, each of them with its own mail server and domain, but a common user base, so a lot of rewriting takes place, we need virtual services for symbolic names like "webmaster" etc.

Postfix/TLS

Some time after having done this I finally found the time to write my TLS extensions for postfix. I took the source of the s_server of the OpenSSL package and added a simplified version of it to postfix, so that by now we can run the SMTP protocol encrypted on the server side. This would also allow us to use plain text password authentication, but as it is available without cost, I rather decided to go with client certificates. If you can offer a client certificate to our server, that is included in a list on our server, you can relay your emails through our server!

Summary

Postfix/TLS is an addition to the smtpd server, which (at least trys to) implement the RFC 2487 TLS Service Extension and allows UCE control based on client certificates. I think it won't be too difficult to also realize the client side of RFC 2487, but this will be a later step.