Le 19/03/2018 à 16:42, Emmanuel Fusté a écrit :
Le 19/03/2018 à 16:28, Wietse Venema a écrit :
Emmanuel Fust?:
Is there any document that describe how interprocess notification is
done in postfix ? More precisely the scheduler -> delivery agent
notification ?
There is no public documentation for *internal* Postfix interfaces,
so that I can change that without breaking non-Postfix software
that depends on Postfix internals.
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.
Please provide quantitative evidence that connection reuse is
necessary to get mail into the 'big providers' (i.e. they punish
connection rate and message rate differently).
Ok I will try to collect data with/without con reuse and get back here.
While reviewing logs, I see that for thousand email being delivered to
the two offending domains, each time the same smtp process will pick the
next mail for the same domain.
So in this particular case, for the most part of the traffic, simply
delaying the closing of the connection (of ~2s max) while taking the
next email would be sufficient to opportunistically reuse the connection
most the time without any inter-process notification modification or
delivery agent TLS refactoring.
I will collect data for TLS vs clear with conn reuse for next week.
---
Emmanuel.
