Matus UHLAR - fantomas:
a smtp client that able to process multiple mails in a single run is not
planned, correct?
On 15.03.18 09:22, Wietse Venema wrote:
Wasn't a dedicated per-destination delivery agent one of the possible
solutions?
if you mean this one:
- For each destination, use dedicated SMTP clients that handle all
TLS sessions with that destination (no inter-process migration),
and cache TCP+TLS state in those processes. Unfortunately, that
does not scale to thousands of destinations.
... which does not scale, I was under impression that it requires site
configuration, or keeping multiple clients alive.
what I meant, is that if SMTP client connecting to destination couldn't
try to deliver multiple (all) mail directed to the destination and then
quit, the only difference would be it could deliver more than just one mail.
I have some problems with big local provider and their crazy (tcp) rate
limiting rules and ugly smtp conf (only one MX, a big LB).
The problem is worse now that all connections are TLS.
(for the detail, their rate limiting is accounted at the LB level and
they host multiple domains).
When I have big mailing running (each Monday), even with
destination_concurrency_limit=1 for a dedicated transport, I get some
gateways temporary blacklisted.
As I understand, by design the scheduler had no way to push "some
destination domain emails" to "some already running delivery agents for
that domain".
Is it a big departure from the current design, but could the protocol
between the scheduler and the delivery agent be augmented with some
"destination_concurrency" over-commit notification containing the domain
for which a to be scheduled email is pending? Before closing the
connection, the agent could check if such a mail is pending.
Yes it is overly complex.
Perhaps we should wait the landing of Linux TLS kernel app sockets which
will perhaps simplify the connection reuse.
I hate to see Exchange be able to push to me multiple emails in a SMTP
TLS connection and not be able to do it with Postfix. ;-)
Emmanuel.
