> On Mar 21, 2018, at 9:46 PM, Wietse Venema <wie...@porcupine.org> wrote:
>
> Just like the SMTP conection cache service, the tlsproxy service
> must not try to do clever things. It receives TLS requirements,
> does a TLS handshake, and returns TLS session properties that can
> later be used to create a connection cache index. If it needs to
> impersonate a delivery agent, then it gets that nanme from the
> Postfix SMTP client.
I'd like to avoid having to fully instantiate the SSL_CTX for each
and every connection, SSL_CTX initialization can be expensive.
Thus, the agent name requirement, and re-use of SSL_CTX built for
previous clients with the same name.
> For obvious scalability reasons, there need to be as many tlsproxy
> processes as needed, so we must not assume that one tlsproxy holds
> all state for all TLS sessions.
Of course, there will be multiple proxy service processes with each
typically serving multiple clients, but only a single proxy service
*definition* in master.cf which handles all the delivery agents.
One could of course choose to dedicate a separate proxy service
for some set of delivery agents via a suitable override of
"smtp_tls_proxy_service_name", but that should not be needed.
All in all this is a non-trivial bit of work...
--
Viktor.
