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 sophisitcated 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 stong 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 standarized 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.
- Authentication of the receiving host to prevent interception.
Status: not realized, yet.
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 pricacy 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 themselve 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.
Other OpenSource packages
Frederik Vermeulen has realized an RFC2487 extension
[QMAILTLS] for the Qmail
[QMAIL] MTA.
Matti Aarnio is working on the server side of RFC2487 for ZMailer
[