> On Dec 13, 2016, at 6:58 AM, Stefan Moravcik <smorav...@newsweaver.com> wrote:
>
> We are not a C development house but have some individuals with a lot of C
> experience that have looked at the code. There are a number of approaches
> that could be taken to help. One of the obvious simple ones for us is to
> keep a connection open in the SMTP process and reuse it if the next email is
> to the same destination (up to a max per connection).
The original prototype of the Postfix connection cache from
which the current scache code evelved was an in-process cache
that re-used a connection when the next connection was to the
same destination as you describe. So this approach is possible
in principle, though not very effective.
The difficult part is making sure that connection re-use is
consistent with policy constraints, so that when multiple
domains share a common MX host or underlying nexthop IP
address, the connection is not reused when the security policy
for the destinations is different (SASL credentials, TLS verification,
...).
The code to do this right is complex, and it has taken some
time to shake out a few subtle issues. So the enthusiasm to
reopen the patient and do new surgery is slim.
One approach that been considered, but not yet implemented
would be an inverse TLS proxy that manages all outbound TLS
connections in process, with SMTP clients connecting to the
proxy (handlng off the initial cleartext connection to the
proxy right after STARTTLS, and handing the *proxy* connection
to scache, instead of the the underlying TLS connection to the
final destination).
This requires figuring out how to split-up the TLS client code
connection setup to do event-based handshake completion (as was
done for TLS proxy in the SMTP server). There would be a small
pool of proxy processes, likely more than 1, but ideally many
fewer than the number of SMTP client processes, with each process
handling multiple connections. Probably the number of proxy
processes should be roughly the number of available CPUs.
This is a difficult project. Only a high quality, well commented
and documented and consistent with existing Postfix code style
implementation can be accepted upstream. If you have access to
top notch talent, and are willing to take the time to study the
current code with care, internalize its style and implement a
reverse TLS proxy for the SMTP client, that could serve the
community at large. Good luck.
As Wietse said, inn the mean-time, if the receiving systems are
struggling to do TLS at volume (surprising really, modern CPUs
can do thousands of TLS handshakes per second), they really
should support TLS session tickets, allowing your clients to
resume sessions more cheaply.
Perhaps the real issue is that *connection* setup (TLS or
otherwise) is too expensive on the remote end. Maybe their
DNS is poorly configured, or they rate-limit connections from
you, ... It would be good to figure out what's going there and
improve throughput by lowering connection setup latency.
--
Viktor.
