On Mon, Aug 08, 2022 at 05:06:22PM -0400, Viktor Dukhovni wrote:
> > We're discussing support for an MUA-specific feature, not high-volime
> > MTA-to-MTA support. Connection reuse is less important, as long as
> > Postfix does not mix traffic with different authentication properties,
> > and that is what SMTP_HOST_KEY is for. So if sharing is a consern,
> > just add a "comes from SRV lookup" flag to the connection cache
> > lookup key.
> >
> > > Are keys along the lines of "domain:submission+srv" too clumsy?
>
> I meant TLS policy lookup keys (smtp_tls_policy_maps). The session and
> connection caches are already fine, since transport name is part of the
> cache key.
Also, for the caches, in addition to not getting false positives from
imprecise keys, we presumably actually want to get cache hits on the
logical destination for connection reuse, which is less likely to happen
if it splits into multiple separate nexthop values.
And perhaps reuse may not be appropriate when the logical nexthop
destinations have different TLS policies, or different SASL settings,
... and yet share underlying submission servers.
So I don't think that a naïve replacement of the nexthop with the
expanded list is semantically sound, if the delivery loop is unaware of
the expansion. These do likely need to behave just like a set of MX
hosts for a single logical destination, only determined via SRV lookup,
with a fancier sorting algorithm and potentially variable per-server
port (variation across the SRV RRset should be rare in practice).
--
Viktor.
