* Viktor Dukhovni :
> Ralf, please try just this patch against the stock 20180618 snapshot,
> and check as many of the below as you can:
>
> * The crashes are gone
> * DANE is still used when expected
> * TLS connection re-use happens under sustained load
>
> We might want to log some sort
Viktor Dukhovni:
>
>
> > On Jun 19, 2018, at 3:07 PM, Wietse Venema wrote:
> >
> > Viktor Dukhovni:
> >> On Jun 19, 2018, at 2:38 PM, Wietse Venema wrote:
> >>> Or alternatively,
> >>> we should save the original "DANE candidate" level for recording
> >>> in the session cache for nexthop entri
> On Jun 19, 2018, at 3:07 PM, Wietse Venema wrote:
>
> Viktor Dukhovni:
>> On Jun 19, 2018, at 2:38 PM, Wietse Venema wrote:
>>> Or alternatively,
>>> we should save the original "DANE candidate" level for recording
>>> in the session cache for nexthop entries, and then use the actual
>>> le
Wietse Venema:
> Viktor Dukhovni:
> > On Jun 19, 2018, at 2:38 PM, Wietse Venema wrote:
> > >
> > > It would not crash, but I don't think it would help.
> > >
> > > First, the scache is indexed with keys that include the TLS security
> > > level for a connection, so that we will never reuse a lo
Viktor Dukhovni:
> On Jun 19, 2018, at 2:38 PM, Wietse Venema wrote:
> >
> > It would not crash, but I don't think it would help.
> >
> > First, the scache is indexed with keys that include the TLS security
> > level for a connection, so that we will never reuse a low-security
> > connection to
On Jun 19, 2018, at 2:38 PM, Wietse Venema wrote:
>
> It would not crash, but I don't think it would help.
>
> First, the scache is indexed with keys that include the TLS security
> level for a connection, so that we will never reuse a low-security
> connection to deliver mail for a high-securit
Viktor Dukhovni:
>
>
> > On Jun 19, 2018, at 1:29 PM, Viktor Dukhovni
> > wrote:
> >
> > In that case, perhaps the below will work?
> >
> > diff --git a/src/smtp/smtp_tls_policy.c b/src/smtp/smtp_tls_policy.c
> > index 13735b21..b5f72376 100644
> > --- a/src/smtp/smtp_tls_policy.c
> > +++ b/s
Viktor Dukhovni:
> On Tue, Jun 19, 2018 at 01:22:53PM -0400, Wietse Venema wrote:
>
> > Unfortunately, this would be suboptimal when a site has muliple MX hosts
> > (It may end up making connections to each of them).
> >
> > Viktor's suggestion to skip the dane cache makes more sense.
> >
> > V
> On Jun 19, 2018, at 1:29 PM, Viktor Dukhovni
> wrote:
>
> In that case, perhaps the below will work?
>
> diff --git a/src/smtp/smtp_tls_policy.c b/src/smtp/smtp_tls_policy.c
> index 13735b21..b5f72376 100644
> --- a/src/smtp/smtp_tls_policy.c
> +++ b/src/smtp/smtp_tls_policy.c
> @@ -824,6
On Tue, Jun 19, 2018 at 01:22:53PM -0400, Wietse Venema wrote:
> Unfortunately, this would be suboptimal when a site has muliple MX hosts
> (It may end up making connections to each of them).
>
> Viktor's suggestion to skip the dane cache makes more sense.
>
> Viktor, cache wshould terminate af
Wietse Venema:
> Ralf, does this helpl?
Unfortunately, this would be suboptimal when a site has muliple MX hosts
(It may end up making connections to each of them).
Viktor's suggestion to skip the dane cache makes more sense.
Viktor, cache wshould terminate after "postfix reload".
> Wiet
Ralf, does this helpl?
Wietse
*** ./smtp_connect.c- 2018-06-04 19:21:21.0 -0400
--- ./smtp_connect.c2018-06-19 13:11:30.0 -0400
***
*** 671,676
--- 671,677
* matching sessions. Otherwise, request a dummy "TLS disabled" policy
* for
> On Jun 19, 2018, at 12:32 PM, Viktor Dukhovni
> wrote:
>
> DANE context initialization needs to know whether the MX hostname
> is an alias, and was previously only done per-MX. Now there's
> a new call with "iter->rr" still NULL. The code in dane_init()
> is not prepared for that. Withou
> On Jun 19, 2018, at 12:21 PM, Wietse Venema wrote:
>
> Argh, the trace ends in the smtp_tls_policy_cache_query which is called from
> more than one place. Investigating...
DANE context initialization needs to know whether the MX hostname
is an alias, and was previously only done per-MX. No
Wietse Venema:
> Viktor Dukhovni:
> >
> >
> > > On Jun 19, 2018, at 11:58 AM, Wietse Venema wrote:
> > >
> > > No error (btw, posttls-finger -X will chdir() to the queue directory,
> > > it just needs root privs).
> > >
> > > So what was the domain that was failing with the Postfix SMTP client
Viktor Dukhovni:
>
>
> > On Jun 19, 2018, at 11:58 AM, Wietse Venema wrote:
> >
> > No error (btw, posttls-finger -X will chdir() to the queue directory,
> > it just needs root privs).
> >
> > So what was the domain that was failing with the Postfix SMTP client?
>
> The crash (from Ralf's sta
> On Jun 19, 2018, at 11:58 AM, Wietse Venema wrote:
>
> No error (btw, posttls-finger -X will chdir() to the queue directory,
> it just needs root privs).
>
> So what was the domain that was failing with the Postfix SMTP client?
The crash (from Ralf's stack trace) was in a code path that is
Ralf Hildebrandt:
> * Wietse Venema :
> > Ralf Hildebrandt:
> > > * Ralf Hildebrandt :
> > >
> > > > Error inducing change was introduced between postfix-3.4-20180603 and
> > > > postfix-3.4-20180605-nonprod
> > >
> > > I also tried postfix-3.4-20180603-nonprod which seems to be working
> > > ok!
* Wietse Venema :
> Ralf Hildebrandt:
> > * Ralf Hildebrandt :
> >
> > > Error inducing change was introduced between postfix-3.4-20180603 and
> > > postfix-3.4-20180605-nonprod
> >
> > I also tried postfix-3.4-20180603-nonprod which seems to be working
> > ok! So I guess it must have been betwee
Ralf Hildebrandt:
> * Ralf Hildebrandt :
>
> > Error inducing change was introduced between postfix-3.4-20180603 and
> > postfix-3.4-20180605-nonprod
>
> I also tried postfix-3.4-20180603-nonprod which seems to be working
> ok! So I guess it must have been between postfix-3.4-20180603-nonprod
> a
* Ralf Hildebrandt :
> Error inducing change was introduced between postfix-3.4-20180603 and
> postfix-3.4-20180605-nonprod
I also tried postfix-3.4-20180603-nonprod which seems to be working
ok! So I guess it must have been between postfix-3.4-20180603-nonprod
and postfix-3.4-20180605-nonprod
-
* Ralf Hildebrandt :
> > Also released as postfix-3.4-20180618.
>
> postfix-3.4-20180618. Is crashing for me:
>
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: private/smtp socket:
> malformed response
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: transport smtp failure --
> see a p
* Ralf Hildebrandt :
> > Also released as postfix-3.4-20180618.
>
> postfix-3.4-20180618. Is crashing for me:
>
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: private/smtp socket:
> malformed response
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: transport smtp failure --
> see a p
> Also released as postfix-3.4-20180618.
postfix-3.4-20180618. Is crashing for me:
Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: private/smtp socket:
malformed response
Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: transport smtp failure --
see a previous warning/fatal/panic logfile r
Wietse Venema:
> Postfix snapshot 20180617, released a few minutes ago, introduces
> Postfix SMTP client support for multiple deliveries per TLS-encrypted
> connection. This is not to be confused with closing a connection
> and reusing some TLS state in a new connection.
Below is a tiny patch for
25 matches
Mail list logo
