# 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.

## Commercial implementations

As far as I know from mailing lists, Netscape Enterprise Server and Microsoft Exchange Server do offer RFC2487 functionality.