> On Aug 17, 2020, at 7:08 PM, admin--- via Exim-dev <exim-dev@???> wrote:
>
> https://bugs.exim.org/show_bug.cgi?id=2265
>
> --- Comment #8 from Jeremy Harris <jgh146exb@???> ---
> Disabling multi_domain turns out to be Extremely Painful because we don't find
> out
> that DANE was used until deep in the transport, well after the addresslist was
> built for a message - combined with all the ways Exim tries to re-use a
> connection for multiple messages. I can see it being a fertile source of bugs.
FWIW, yes connection and TLS session reuse are tricky in the context of potentially
different security policies for different destinations. This is a source of some
non-trivial complexity in the Postfix SMTP client.
The session and connection caches have multi-element lookup keys (run through
SHA256 in the case of the session cache) that combine some of the following
(partial list):
- transport (router) name
- nexthop domain
- TLS security level
- SNI name
- Remote IP address
- Remote name from first line ("250-<hostname>") of EHLO
- DANE TLSA RRset
- TLS reference identifiers (names to check in the cert)
- ...
This took quite time and effort to build, and there are dedicated
functions for constructing the lookup keys for saving and retrieving
live connections and cached TLS sessions.
The Exim case should be somewhat simpler since nothing is persisted
out of process, but also trickier, because you're trying to collect
multiple messages to send down the connection in real time, rather
than squirreling away the connection for potential reuse by another
separate delivery.
I don't know anything about the internals of multi-domain support
in Exim, but can see that this could be a pain. And yet, it is
largely an unavoidable issue. The security constraints do mean
that some messages that would otherwise be grouped for transmission
over a single channel, can no longer be correctly grouped that way.
--
Viktor.
