Postfix/TLS - Introduction
Postfix/TLS is an extension of the Postfix [POSTFIX] MTA software to support the
TLS protocol.
A note about the start of the project
When I started writing this software, I had a sophisticated way to
allow relaying for roaming users in
mind. In the meantime, this project is living on its own.
RFC2246: The TLS (former SSL) protocol
By default all communication on the Internet is done without
encryption and without strong authentication. That does mean that
everybody with physical access to the communication line along
which a network packet will travel can eavesdrop on your
communication. Even worse, it might be possible to redirect or
alter your communication so that information, that you want to send
to a party can be lost or changed without your notice.
In order to solve these security issues, the SSL protocol
(Secure Socket Layers) was introduced by Netscape, Inc., which now
has evolved into the standardised TLS protocol (Transportation
Layer Security) as RFC2246. It offers
both encryption of the communication (stopping eavesdropping) and
strong authentication (making sure that both parties of a
communication are correctly identified and that the communication
cannot be altered).
Postfix/TLS does not realize the TLS protocol itself; it rather
uses the OpenSSL package [OPENSSL] for this task. At the
OpenSSL WWW-site you can also find links to in-depth documentation
of the protocol and its features, so that it is not necessary to
included them here. (And, of course, there is no use of re-writing
what other people already wrote down, it just introduces additional
errors.)
RFC2487: Introducing TLS to SMTP
The integration of the TLS protocol to Internet mail, SMTP (Simple
Mail Transport Protocol) is described in
RFC2487.
Unlike the first incarnations of SSL as a wrapper
around normal network communications [STUNNEL] [JONAMA], the TLS protocol is now
completely integrated into the ESMTP: during the startup
negotiation (EHLO) the server offers the support of TLS by
advertising the STARTTLS feature. The client can
now send the STARTTLS command to do authentication
and switch to encrypted communication.
Postfix/TLS: what can it do for you
The list of features presented here should be understood as a list
of ideas. Not all of them are realized yet, please see the notes at
each feature.
- Encrypted email transfer from one host to another.
Status: realized.
Comment: Once the STARTTLS negotiation is finished, the
communication between both parties is encrypted.
This also includes the MAIL FROM: and RCPT TO: envelop sender
and recipient negotiation, so that an eavesdropper will not be able
to get these informations.
- Authentication of the receiving host to prevent
interception.
Status: realized.
Comment: This is a quite important feature that is not difficult to
implement. The problem lies in the fact, that not all hosts (read
this: by now nearly no one) support this protocol. The sender must
hence maintain a list of receivers which must identify by TLS,
otherwise one could just intercept the communication and not offer
STARTTLS, so that no authentication is done. One must also be
careful to use the correct name of the host (see CNAMEs), but this
problem is the same for http-servers.
- Authentication of the sending host to prevent forgery.
Status: Difficult to do.
Comment: The transmission of emails is just a connection to the
SMTP port (25) of the receiving host. This is done by either
another MTA (Mail Transport Agent) or a MUA (Mail User Agent). In
the first case, the sending MTA should present a client certificate
issued on the name of the sending host. In the latter case however,
the user has no access to the host's certificate and will (or not)
present his own personal certificate. At this point I think that a
satisfying and reliable solution is hardly possible (do
you want your users' email bounce without reason?), so it has least
priority.
- Authentication of the sending host to allow relaying.
Status: realized.
Comment: This was the intention I had in mind when starting this
project, so it was realized first. Based on the certificate the
client MTA or MUA presents to the server, relaying can be
allowed.
- Any more ideas???
Status: Send me an email.
Postfix/TLS: what it cannot do for you
There is one thing that I explicitly want to point out:
- Securing the privacy of your email.
Status: Cannot be done.
Comment: RFC2487 only takes care of the transportation between mail
servers. To assure that nobody can eavesdrop on your private email
communication, it would be necessary that
- all of the mailhubs in between are enforcing TLS.
- all mailhubs themselves are trustworthy, as the email is only
encrypted during transport, not when queued or spooled.
- the destination is trustworthy, as the mail is spooled in clear
and everybody who can access your mailbox (read this: at least the
superuser) can read your mail!
Hence, if you want privacy, you have to send out your
email encrypted, e.g. using S/MIME or the traditional PGP
package.
- Authenticate the sender of an email.
Status: Cannot be done.
Comment: A lot of MUAs send out emails by just connecting the SMTP
port of the sending host or nearest mailhub. There is no way to
assure that the sender listed in the email is the real sender of
the email. And even if it would be possible to identify the sender,
the contents of the email might have been altered in between.
To ensure the identity of the sender and the integrity of the
email, you can again use S/MIME or PGP.
Support by Mail User Agents
The following MUAs are known to work with RFC2487:
- Netscape >= 4.5 supports STARTTLS and client certificates.
- Outlook (Express) >= 5 supports STARTTLS (only on port 25) and traditional
SSL-wrapping style (on all other ports). No support for client certificates.
- Eudora >= 5.1 supports STARTTLS. Client certificate status unknown.
Other OpenSource packages
As of version sendmail-8.11, sendmail includes RFC2487 support [SENDMAIL].
Frederik Vermeulen has realized an RFC2487 extension [QMAILTLS] for the Qmail [QMAIL] MTA.
Matti Aarnio has integrated RFC2487 into ZMailer [ZMAILER].
Michal Trojnara is currently integrating basic SMTP support into
his stunnel software, starting with stunnel-3.3 [STUNNEL].
Trey Childs is also working on a "wrapper" solution [SMTPS].
Commercial implementations
The commercial version of sendmail includes RFC2487 support [SENDMAIL.INC].
Netscape Enterprise Server and Microsoft Exchange Server do offer
RFC2487 functionality.
The CommunigatePro mailserver software also supports RFC2487
[COMMUNIGATE].