> On Jun 19, 2018, at 1:29 PM, Viktor Dukhovni <postfix-us...@dukhovni.org> 
> 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 +824,20 @@ static void dane_init(SMTP_TLS_POLICY *tls, 
> SMTP_ITERATOR *iter)
>       dane_incompat(tls, iter, NONDANE_DEST, "non DNSSEC destination");
>       return;
>     }
> +
> +    /*
> +     * Without the context of a particular MX host, the nexthop is merely a
> +     * opportunistic "candidate" for DANE policy.  Just return "may" for now.
> +     *
> +     * XXX: This state should only be reached from smtp_reuse_session(),
> +     * perhaps add a safety flag in iter that is co-requisite with a NULL
> +     * iter->rr, or else panic?
> +     */
> +    if (!iter->rr) {
> +     tls->level = TLS_LEV_MAY;
> +     return;
> +    }
> +
>     /* When TLSA lookups fail, we defer the message */
>     if ((dane = tls_dane_resolve(iter->port, "tcp", iter->rr,
>                                var_smtp_tls_force_tlsa)) == 0) {

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 of connection identifier
with re-used connections, that would make it possible
reliably find the original session to check that it
was authenticated as expected.  This is only useful
with TLS, so we could perhaps ask the TLS library for
"channel binding" at session creation, and log it
(on both ends) with the client logging it again on
*connection* re-use.  (TLS session resumption is
a separate matter and would produce a separate
channel fingerprint on each connection).

-- 
        Viktor.

Reply via email to