Wietse Venema:
> I agree with Viktor that updating the TLS proxy is the more feasible
> approach (caching the TLS sessions outside delivery agents). I also
> don't believe in changing the scheduler-to-delivery agent protocol.
> The Postfix approach is not to make an existing thing more complex,
> but by combining less complex things together.
A basic outline would look like the text below. This is the same
code path as for plaintext connection caching, with minor changes.
- The Postfix SMTP client looks up MX and perhaps TLSA records.
Then it does a per-destination connection cache lookup. The cache
lookup key identifies the destination and other session properties.
The only new thing here is that the lookup key will also identify
TLS properties.
- If no cached session is found, the Postfix SMTP client iterates
over MX hosts and do per-MX connection cache lookups, with again
the lookup key identifying the MX host IP address and other connection
properties. Again, the only new thing here is that the lookup key
will also identify TLS properties.
- If a cached session is found, the Postfix SMTP client reuses it;
this is the same client-side logic as with cached plaintext
connections.
- At some point the Postfix SMTP client decides to create a new
connection. It goes through the plaintext EHLO handshake, then sends
the plaintext STARTTLS command. If the server accepts the command,
the client connects to a tlsproxy daemon, sends it the desired TLS
properties, and the open plaintext SMTP connection. The tlsproxy
daemon completes the TLS handshake and sends returns some TLS session
peroperties to the Postfix SMTP client.
- The Postfix SMTP client sends plaintext SMTP commands through the
tlsproxy daemon and receives plaintext responses through the tlsproxy
daemon. The tlsproxy daemon encrypts outgoing data and sends it to
the remote SMTP server, and decrypts incoming data from the remote
SMTP server before sending it to the Postfix SMTP client. This
looks like something new, but the tlsproxy daemon is already doing
similar things for the postscreen daemon.
- At the end of normal delivery, the Postfix SMTP client caches the
plaintext connection as usual. The cache lookup key identifies the
destination and other connection properties. The only new thing is
that the lookup key will also identify TLS properties, and of course
that the plaintext connection goes to a tlsproxy daemon instead of a
remote SMTP server. Additionally, the Postfix SMTP client caches
the connection under a lookup key that identifies the MX host IP
address plus other session and TLS properties.
So, most of the effort is 1) serialize and deserialize the desired
TLS properties and the properties of an established session, 2)
complete any missing tlsproxy parts to support outbound connections,
3) duplicate some TLSA logic in the tlsproxy daemon, if it can't
be factored out into a reusable library.
Wietse
