> On Mar 22, 2018, at 1:22 PM, Wietse Venema wrote:
>
> Well, each Postfix SMTP client creates SSL_CTX once, then reuses
> it across multiple TLS sessions. I suppose that tlsproxy can share
> this object among all sessions that tlsproxy creates for SMTP clients
> with similar parameters. This i
Viktor Dukhovni:
>
>
> > On Mar 22, 2018, at 10:54 AM, Wietse Venema wrote:
> >
> > Currently, the Postfix SMTP client does a bunch of TLS initialization,
> > once per TLS session.
>
> The expensive stuff for SSL_CTX happens only once in tls_client_init().
> You're only looking at tls_client_s
> On Mar 22, 2018, at 10:54 AM, Wietse Venema wrote:
>
> Currently, the Postfix SMTP client does a bunch of TLS initialization,
> once per TLS session.
The expensive stuff for SSL_CTX happens only once in tls_client_init().
You're only looking at tls_client_start(), which uses a previously
ini
Viktor Dukhovni:
>
>
> > On Mar 21, 2018, at 9:46 PM, Wietse Venema 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
> On Mar 21, 2018, at 9:46 PM, Wietse Venema 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 c
Viktor Dukhovni:
> My point was that we'd still want a single proxy service, so it will need
> to be aware of the connecting transport name, and configure a suitable
> SSL_CTX when that name is seen for the first time. Session resumption
> would also need to convey the delivery agent name to tlsmg
> On Mar 21, 2018, at 10:48 AM, Wietse Venema wrote:
>
>> It is probably time to refactor the original Postfix 2.11 DANE internals
>> to look a lot more like the new DANE API in OpenSSL 1.1.0, which should
>> serialize a bit more easily.
>>
>> One complication is that we often have more than o
Viktor Dukhovni:
>
>
> > On Mar 20, 2018, at 11:34 PM, Wietse Venema wrote:
> >
> > 3) duplicate some TLSA logic in the tlsproxy daemon, if it can't
> > be factored out into a reusable library.
>
> It is probably time to refactor the original Postfix 2.11 DANE internals
> to look a lot more li
> On Mar 20, 2018, at 11:34 PM, Wietse Venema wrote:
>
> 3) duplicate some TLSA logic in the tlsproxy daemon, if it can't
> be factored out into a reusable library.
It is probably time to refactor the original Postfix 2.11 DANE internals
to look a lot more like the new DANE API in OpenSSL 1.1.
Wietse Venema:
> 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,
> b
Hello Wietse,
I was reading this topic with interest because this issue affects me very
much as well.
I had a slowness issue when sending to @hotmail.* . I tried all the
Microsoft services in order to check how I was seen from them and I got
confirmation that I was OK. I received this information
Le 19/03/2018 à 17:32, Msd a écrit :
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
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 f
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.
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 c
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 so
Le 18/03/2018 à 19:23, Viktor Dukhovni a écrit :
On Mar 18, 2018, at 1:55 PM, Matus UHLAR - fantomas 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. Th
> On Mar 18, 2018, at 1:55 PM, Matus UHLAR - fantomas 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'
On Mar 15, 2018, at 10:38 AM, Karol Augustin 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 auto
@lbutlr:
> On 2018-03-16 (05:10 MDT), Wietse Venema 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
On 2018-03-16 (05:10 MDT), Wietse Venema 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 g
@lbutlr:
> On 2018-03-15 (09:01 MDT), Viktor Dukhovni =
> 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 con
On 2018-03-15 (09:01 MDT), Viktor Dukhovni 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
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 de
> On Mar 15, 2018, at 10:38 AM, Karol Augustin 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-
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 dedi
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 comple
>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 Vene
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 TL
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:
In
ned 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 cl
reasing 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.
32 matches
Mail list logo
