SMTP session caching

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

SMTP session caching

A. Schulze
Hello,

I like to ask about a documented limitation (http://www.postfix.org/CONNECTION_CACHE_README.html#limitations)

"For this reason, the Postfix smtp(8) client always closes the connection after completing an attempt to deliver mail over TLS."

I'm concerned becaus I see increasing traffic delivered via TLS.
It is true that now /every single message/ require TCP connect, TLS Handshake, message transmission and TCP close?
So SMTP Session caching don't happen anymore?

Given a sending server handle 3000 messages per hour to a specific destination that use DANE.
Virtually every 1-2 seconds the server open and close a connection. Why shouldn't it be possible
to recycle an established connection for multiple message?

I only like to /understand/ the above "this reason" ...

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Wietse Venema
A. Schulze:
> Hello,
>
> I like to ask about a documented limitation
> (http://www.postfix.org/CONNECTION_CACHE_README.html#limitations)
>
> "For this reason, the Postfix smtp(8) client always closes the
> connection after completing an attempt to deliver mail over TLS."

Indeed. Postfix can migrate the TCP connection from one process to
another, but the TLS library does not support migration of live TLS
state. It supports reuse on new connections only.

Possible solutions would be:

- Don't worry about it.  Postfix connection caching keeps TCP
connections open for only a few seconds, whereas TLS session tickets
have much larger lifetimes. Unless your use case is very specialized,
you would not be reusing TCP connections often anyway.

- Implement inter-process migration of live TLS state in the TLS
library. This is unlikely because the use case is specific to MTAs
that have a multi-process implementation.

- 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.

- Use a single-process implementation for TLS, and cache TCP+TLS
state in that process. That would be a departure from Postfix's
multi-process model, but we already have this for non-whitelisted
clients handled by postscreen+tlsproxy. It would make Postfix more
fragile.

> I'm concerned becaus I see increasing traffic delivered via TLS.
> It is true that now /every single message/ require TCP connect,
> TLS Handshake, message transmission and TCP close?  So SMTP Session
> caching don't happen anymore?

TCP handshake, TLS session ticket reuse, TLS shutdown, TCP close.

The Postfix SMTP client keeps (plaintext) TCP connections open for
only a few seconds, so yould not be reusing TCP connections often
unless you have a very specialized use case. With TLS, the session
tickets give more benefit because they have longer lifetimes.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Matus UHLAR - fantomas
>A. Schulze:
>> I like to ask about a documented limitation
>> (http://www.postfix.org/CONNECTION_CACHE_README.html#limitations)
>>
>> "For this reason, the Postfix smtp(8) client always closes the
>> connection after completing an attempt to deliver mail over TLS."

On 07.03.18 09:07, Wietse Venema wrote:
>Indeed. Postfix can migrate the TCP connection from one process to
>another, but the TLS library does not support migration of live TLS
>state. It supports reuse on new connections only.
>
>Possible solutions would be:

a smtp client that able to process multiple mails in a single run is not
planned, correct?

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam is for losers who can't get business any other way.
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Wietse Venema
Matus UHLAR - fantomas:

> >A. Schulze:
> >> I like to ask about a documented limitation
> >> (http://www.postfix.org/CONNECTION_CACHE_README.html#limitations)
> >>
> >> "For this reason, the Postfix smtp(8) client always closes the
> >> connection after completing an attempt to deliver mail over TLS."
>
> On 07.03.18 09:07, Wietse Venema wrote:
> >Indeed. Postfix can migrate the TCP connection from one process to
> >another, but the TLS library does not support migration of live TLS
> >state. It supports reuse on new connections only.
> >
> >Possible solutions would be:
>
> a smtp client that able to process multiple mails in a single run is not
> planned, correct?

Wasn't a dedicated per-destination delivery agent one of the possible
solutions?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Matus UHLAR - fantomas
>> >A. Schulze:
>> >> I like to ask about a documented limitation
>> >> (http://www.postfix.org/CONNECTION_CACHE_README.html#limitations)
>> >>
>> >> "For this reason, the Postfix smtp(8) client always closes the
>> >> connection after completing an attempt to deliver mail over TLS."
>>
>> On 07.03.18 09:07, Wietse Venema wrote:
>> >Indeed. Postfix can migrate the TCP connection from one process to
>> >another, but the TLS library does not support migration of live TLS
>> >state. It supports reuse on new connections only.
>> >
>> >Possible solutions would be:

>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.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Your mouse has moved. Windows NT will now restart for changes to take
to take effect. [OK]
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Karol Augustin
On 2018-03-15 13:58, Matus UHLAR - fantomas wrote:

>>> >A. Schulze:
>>> >> I like to ask about a documented limitation
>>> >> (http://www.postfix.org/CONNECTION_CACHE_README.html#limitations)
>>> >>
>>> >> "For this reason, the Postfix smtp(8) client always closes the
>>> >> connection after completing an attempt to deliver mail over TLS."
>>>
>>> On 07.03.18 09:07, Wietse Venema wrote:
>>> >Indeed. Postfix can migrate the TCP connection from one process to
>>> >another, but the TLS library does not support migration of live TLS
>>> >state. It supports reuse on new connections only.
>>> >
>>> >Possible solutions would be:
>
>>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 think what Matus is asking here is the RSET implementation in postfix
client. For example I have software that send some automated e-mail over
night using single SMTP connection (written in perl). After each e-mail
it does $smtp->reset(); and than delivers next e-mail using the same
connection. Final effect looks like that:

disconnect from localhost[127.0.0.1]:51596 ehlo=1 mail=63 rcpt=71
data=63 rset=63 quit=1 commands=262

I believe Matus is asking if that could be implemented in postfix so it
connects to remote SMTP server and delivers one e-mail after another
issuing RSET after each one and not disconnecting.

Karol


--
Karol Augustin
[hidden email]
http://karolaugustin.pl/
+353 85 775 5312
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Emmanuel Fusté-2
In reply to this post by Matus UHLAR - fantomas

>> 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.
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Viktor Dukhovni
In reply to this post by Karol Augustin


> On Mar 15, 2018, at 10:38 AM, Karol Augustin <[hidden email]> wrote:
>
> I think what Matus is asking here is the RSET implementation in postfix
> client. For example I have software that send some automated e-mail over
> night using single SMTP connection (written in perl). After each e-mail
> it does $smtp->reset(); and than delivers next e-mail using the same
> connection. Final effect looks like that:
>
> disconnect from localhost[127.0.0.1]:51596 ehlo=1 mail=63 rcpt=71
> data=63 rset=63 quit=1 commands=262
>
> I believe Matus is asking if that could be implemented in postfix so it
> connects to remote SMTP server and delivers one e-mail after another
> issuing RSET after each one and not disconnecting.

Yes, this much is clear, but the architectural constraints are difficult.

   * Live SSL connections (rather than cached sessions) cannot be migrated
     across processes.

   * SMTP STARTTLS does not have a STOPTLS counterpart that would allow
     the connection state to return to cleartext with TLS resumption on
     re-use.  This could be introduced, but would take many years to be
     implemented on some non-trivial fraction of servers.

   * Using TLS proxy processes for outbound TLS connections requires
     complex new code and increases the Postfix memory footprint, and
     may reduce throughput under load (when all the destination's MX
     hosts are up and accept connections quickly).

   * Caching open TLS connections in the smtp(8) delivery agent for
     reuse by scheduling repeated deliveries to the same delivery
     agent runs into complex scheduling difficulties.  The presence
     of open connections don't, and should not IMHO alter scheduler
     priority.  Messages should still leave in approximately FIFO
     order (subject to (n)qmgr's periodic preemption of messages that
     split into many envelopes).

Given the above the least bad is IMHO the proxy approach, with all
TLS processing in a pool of outbound TLS proxy processes, with the
cached connections being cleartext from the delivery agent to the
proxy.

This would be a rather non-trivial effort.  And downstream MTAs
at major providers seem to frown on connection re-use these days.
While traffic to smaller destinations is typically less
performance-critical.  So while having TLS connection caching
would be nice, it is not clear that it is a high priority given
the high cost and possibly only moderate benefit.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Wietse Venema
In reply to this post by Matus UHLAR - fantomas
Matus UHLAR - fantomas:

> >> >A. Schulze:
> >> >> I like to ask about a documented limitation
> >> >> (http://www.postfix.org/CONNECTION_CACHE_README.html#limitations)
> >> >>
> >> >> "For this reason, the Postfix smtp(8) client always closes the
> >> >> connection after completing an attempt to deliver mail over TLS."
> >>
> >> On 07.03.18 09:07, Wietse Venema wrote:
> >> >Indeed. Postfix can migrate the TCP connection from one process to
> >> >another, but the TLS library does not support migration of live TLS
> >> >state. It supports reuse on new connections only.
> >> >
> >> >Possible solutions would be:
>
> >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.

Indeed.

> 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.

Indeed. And there is no scalable approach for doing that.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

@lbutlr
In reply to this post by Viktor Dukhovni
On 2018-03-15 (09:01 MDT), Viktor Dukhovni <[hidden email]> wrote:
>
> Caching open TLS connections in the smtp(8) delivery agent for
>     reuse by scheduling repeated deliveries to the same delivery
>     agent runs into complex scheduling difficulties.  The presence
>     of open connections don't, and should not IMHO alter scheduler
>     priority.  Messages should still leave in approximately FIFO
>     order (subject to (n)qmgr's periodic preemption of messages that
>     split into many envelopes).

Isn't the issue a short-term one, where for example, a thousand mails hit the queue and 400 are for gmail.com and the desired behavior is to send those 400 in one connection whilst the others get queued up via a separate process?

This could be done with a queue scheduler that pre-processes the queue when "a lot" of messages get queued for sending and then sorts them based on destination and the destinations that exceed some pre-defined threshold get shunted to a separate process.

That seems like it is doable, if not simple. Heck, it could even only work if the messages were queued in order. Something along the lines of "I'm connected to big.example.com, is the next message to big.example.com? It is? OK, reuse this connection."

This approach would do nothing about multi-destination emails, but I suspect that what is wanted by people in this thread doesn't involve multi-destination emails.

--
<http://www.pvponline.com/comic/2004/01/14/wed-jan-14/>

Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Wietse Venema
@lbutlr:

> On 2018-03-15 (09:01 MDT), Viktor Dukhovni <[hidden email]> =
> wrote:
> >=20
> > Caching open TLS connections in the smtp(8) delivery agent for
> >     reuse by scheduling repeated deliveries to the same delivery
> >     agent runs into complex scheduling difficulties.  The presence
> >     of open connections don't, and should not IMHO alter scheduler
> >     priority.  Messages should still leave in approximately FIFO
> >     order (subject to (n)qmgr's periodic preemption of messages that
> >     split into many envelopes).
>
> Isn't the issue a short-term one, where for example, a thousand mails =
> hit the queue and 400 are for gmail.com and the desired behavior is to =
> send those 400 in one connection whilst the others get queued up via a =
> separate process?
>
> This could be done with a queue scheduler that pre-processes the queue =
> when "a lot" of messages get queued for sending and then sorts them =
> based on destination and the destinations that exceed some pre-defined =
> threshold get shunted to a separate process.
>
> That seems like it is doable, if not simple. Heck, it could even only =
> work if the messages were queued in order. Something along the lines of =
> "I'm connected to big.example.com, is the next message to =
> big.example.com? It is? OK, reuse this connection."

Currently, the Postfix scheduler will read all your 1000 recipients
from the queue (the read limit is 20000). Currently, Postfix will
deliver all your 400 to gmail.com AND AT THE SAME TIME deliver 600
to other destinations.

With your proposal, Postfix will deliver 400 to gmail.com (leaving
many Postfix delivery agents unused) and ignore those 600 until the
400 are delivered. That would be a regression.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

@lbutlr
On 2018-03-16 (05:10 MDT), Wietse Venema <[hidden email]> wrote:
>
> @lbutlr:
>>
>> This could be done with a queue scheduler that pre-processes the queue when "a lot" of messages get queued for sending and then sorts them based on destination and the destinations that exceed some pre-defined threshold get shunted to a separate process.
>
> Currently, the Postfix scheduler will read all your 1000 recipients from the queue (the read limit is 20000). Currently, Postfix will deliver all your 400 to gmail.com AND AT THE SAME TIME deliver 600 to other destinations.
>
> With your proposal, Postfix will deliver 400 to gmail.com (leaving many Postfix delivery agents unused) and ignore those 600 until the 400 are delivered. That would be a regression.

That's certainly not what I meant by "a separate process".

Anyway, it's not a feature I need/want/care about, I was just suggesting a way I thought it *could* be made to work.


--
Because you liked "The Very Hungry Caterpillar" may we suggest "The
Human Centipede"?

Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Wietse Venema
@lbutlr:

> On 2018-03-16 (05:10 MDT), Wietse Venema <[hidden email]> wrote:
> >=20
> > @lbutlr:
> >>=20
> >> This could be done with a queue scheduler that pre-processes the =
> queue when "a lot" of messages get queued for sending and then sorts =
> them based on destination and the destinations that exceed some =
> pre-defined threshold get shunted to a separate process.
> >=20
> > Currently, the Postfix scheduler will read all your 1000 recipients =
> from the queue (the read limit is 20000). Currently, Postfix will =
> deliver all your 400 to gmail.com AND AT THE SAME TIME deliver 600 to =
> other destinations.
> >=20
> > With your proposal, Postfix will deliver 400 to gmail.com (leaving =
> many Postfix delivery agents unused) and ignore those 600 until the 400 =
> are delivered. That would be a regression.
>
> That's certainly not what I meant by "a separate process".

I hope you did not mean 'one' process, becasue that would be slow.
Perhaps something that is more similar to creating a temporary
master.cf transport, with a limited collection of delivery agents.

        Wietse

> Anyway, it's not a feature I need/want/care about, I was just suggesting =
> a way I thought it *could* be made to work.
>
>
> --=20
> Because you liked "The Very Hungry Caterpillar" may we suggest "The=20
> Human Centipede"?
>
>
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Matus UHLAR - fantomas
In reply to this post by Viktor Dukhovni
>> On Mar 15, 2018, at 10:38 AM, Karol Augustin <[hidden email]> wrote:
>> I think what Matus is asking here is the RSET implementation in postfix
>> client.

Actually no - I don't see any reason to use RSET, unless a problem appears.
Is it needed without error appearing?

>> For example I have software that send some automated e-mail over
>> night using single SMTP connection (written in perl). After each e-mail
>> it does $smtp->reset(); and than delivers next e-mail using the same
>> connection. Final effect looks like that:
>>
>> disconnect from localhost[127.0.0.1]:51596 ehlo=1 mail=63 rcpt=71
>> data=63 rset=63 quit=1 commands=262
>>
>> I believe Matus is asking if that could be implemented in postfix so it
>> connects to remote SMTP server and delivers one e-mail after another
>> issuing RSET after each one and not disconnecting.

On 15.03.18 11:01, Viktor Dukhovni wrote:
>Yes, this much is clear, but the architectural constraints are difficult.
>
>   * Live SSL connections (rather than cached sessions) cannot be migrated
>     across processes.

This is precisely why I asked, if this can be done within one process -
no interprocess migration needed.

If a single smtp process (that alread did the TLS handshake) could deliver
multiple mail, when there is mail in queue for the same destination.

This could give us performance advantage in cases when there are more mails
in the queue than our smtp_destination_concurrency_limit.

It could be faster in case of SMTP destination refusing connections over
its limit, when our smtp_destination_concurrency_limit is not full yet
(and thus postfix tries to open new connections that are refused and mail is
delayed).

It would also help in case of unreachable servers - if SMTP client found
working server for a destination, it could pass multiple mail to it.

>   * Using TLS proxy processes for outbound TLS connections requires
>     complex new code and increases the Postfix memory footprint, and
>     may reduce throughput under load (when all the destination's MX
>     hosts are up and accept connections quickly).

This is just what am I asking for - how much of new code or complexity it
requires.

I have no knowledge of postfix stycture and the docs at
http://www.postfix.org/OVERVIEW.html#delivering
don't explain it in detail.

so I can only ask and speculate..

>   * Caching open TLS connections in the smtp(8) delivery agent for
>     reuse by scheduling repeated deliveries to the same delivery
>     agent runs into complex scheduling difficulties.  The presence
>     of open connections don't, and should not IMHO alter scheduler
>     priority.  Messages should still leave in approximately FIFO
>     order (subject to (n)qmgr's periodic preemption of messages that
>     split into many envelopes).

I believe routing multiple messages for the same destination through an
array of currently open connections (held by different processes) should
not be slower than opening new connection for each message.

>This would be a rather non-trivial effort.  And downstream MTAs
>at major providers seem to frown on connection re-use these days.

is there an evidence about this?

>While traffic to smaller destinations is typically less
>performance-critical.  So while having TLS connection caching
>would be nice, it is not clear that it is a high priority given
>the high cost and possibly only moderate benefit.

that is imho still the question. But I'm more curious about questions above
:-)

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Save the whales. Collect the whole set.
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Viktor Dukhovni
> On Mar 18, 2018, at 1:55 PM, Matus UHLAR - fantomas <[hidden email]> wrote:
>
>> * Caching open TLS connections in the smtp(8) delivery agent for
>>    reuse by scheduling repeated deliveries to the same delivery
>>    agent runs into complex scheduling difficulties.  The presence
>>    of open connections don't, and should not IMHO alter scheduler
>>    priority.  Messages should still leave in approximately FIFO
>>    order (subject to (n)qmgr's periodic preemption of messages that
>>    split into many envelopes).
>
> I believe routing multiple messages for the same destination through an
> array of currently open connections (held by different processes) should
> not be slower than opening new connection for each message.
>
>> This would be a rather non-trivial effort.  And downstream MTAs
>> at major providers seem to frown on connection re-use these days.
>
> is there an evidence about this?
>
>> While traffic to smaller destinations is typically less
>> performance-critical.  So while having TLS connection caching
>> would be nice, it is not clear that it is a high priority given
>> the high cost and possibly only moderate benefit.
>
> that is imho still the question. But I'm more curious about questions above

Sorry, no cycles to dissect this point by point.  My view is as stated in
the previous message:

  * I believe that support for this requires proxy processes to handle TLS
    on behalf of (multiple) SMTP delivery agents.  The connection cache
    would then hold a connection to the proxy, rather than a connection to
    the remote destination.

  * The feature is attractive, but not urgently compelling.  It is complex
    to implement, so I cannot predict when work in that direction might begin.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Emmanuel Fusté-2
Le 18/03/2018 à 19:23, Viktor Dukhovni a écrit :

>> On Mar 18, 2018, at 1:55 PM, Matus UHLAR - fantomas <[hidden email]> wrote:
>>
>>> * Caching open TLS connections in the smtp(8) delivery agent for
>>>     reuse by scheduling repeated deliveries to the same delivery
>>>     agent runs into complex scheduling difficulties.  The presence
>>>     of open connections don't, and should not IMHO alter scheduler
>>>     priority.  Messages should still leave in approximately FIFO
>>>     order (subject to (n)qmgr's periodic preemption of messages that
>>>     split into many envelopes).
>> I believe routing multiple messages for the same destination through an
>> array of currently open connections (held by different processes) should
>> not be slower than opening new connection for each message.
>>
>>> This would be a rather non-trivial effort.  And downstream MTAs
>>> at major providers seem to frown on connection re-use these days.
>> is there an evidence about this?
>>
>>> While traffic to smaller destinations is typically less
>>> performance-critical.  So while having TLS connection caching
>>> would be nice, it is not clear that it is a high priority given
>>> the high cost and possibly only moderate benefit.
>> that is imho still the question. But I'm more curious about questions above
> Sorry, no cycles to dissect this point by point.  My view is as stated in
> the previous message:
>
>    * I believe that support for this requires proxy processes to handle TLS
>      on behalf of (multiple) SMTP delivery agents.  The connection cache
>      would then hold a connection to the proxy, rather than a connection to
>      the remote destination.
>
>    * The feature is attractive, but not urgently compelling.  It is complex
>      to implement, so I cannot predict when work in that direction might begin.
>
Ok, this is for the connection reuse in the traditional postfix
sense.Some "opportunistic" reuse.

But would it be difficult to implement something for the case when the
connection reuse could be planned by the scheduler before submission to
the agents ?

The most problematic case (and the case for which we would gain a lot)
is when we cross by a factor the transport_destination_concurrency_limit
of mail waiting to be delivered to a destination in the mailq.

In this case, instead of pushing/notifying smtp one mail at time, could
the notifying scheme be extended to be able to push a list of mail to be
processed by one smtp agent ?
With purely static parameters (crossing factor and fixed queue length)
it could be a huge step forward for the most common case, even with low
queue length and could be later enhanced if wanted (dynamic or adaptive
queue length for example).

In my case, I already have transport_destination_concurrency_limit=1 for
the problematic destinations and many parallels servers with their own
public IP. At the scale of my country, the problematic destination is
like google or yahoo for the world. Without connection reuse for
lowering my tcp connexion rate, my servers are always throttled
(temporary blacklisted).
Now my only option would be to disable TLS for these domains, but my
client will put me on fire or more in that case |-)).

Is there any document that describe how interprocess notification is
done in postfix ? More precisely the scheduler -> delivery agent
notification ?

---
Emmanuel.
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Wietse Venema
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).

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Emmanuel Fusté-2
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.

---
Emmanuel.
Msd
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Msd
In reply to this post by Wietse Venema
Le 19/03/2018 à 16:28, Wietse Venema a écrit :
> 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).

Hi Wietse,

The biggest email service provider in France : Orange/Wanadoo.

We needed to disable TLS to reuse connections :
postconf -P "orange/unix/smtp_tls_security_level=none"

Here are their rules, got from [hidden email] and confirmed by our logs :
- Maximum 1000 connections per hour
- Maximum 100 emails by connection
- Maximum 3 simultaneous connections

A website about that :
http://www.delivernow.eu/en/european-isp/orange-protects-its-messaging-infrastructure-with-cloudmark-antispam-solution-3

Sample of SMTP reply in case of problem :

> smtp-in.orange.fr[193.252.22.65] refused to talk to me: 421 mwinf5c01 ME
> Service refuse. Veuillez essayer plus tard. Service refused, please try
> later. OFR005_105 [105]

> host smtp.wanadoo.fr[80.12.242.15] refused to talk to me: 421
> mwinf5c26 ME Trop de connexions, veuillez verifier votre
> configuration. Too many connections, slow down. OFR004_104 [104]


Guillaume
Reply | Threaded
Open this post in threaded view
|

Re: SMTP session caching

Emmanuel Fusté-2
In reply to this post by Emmanuel Fusté-2
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.
12