Viktor Dukhovni:
> On Mon, Aug 08, 2022 at 04:07:39PM -0400, Wietse Venema wrote:
> > Viktor Dukhovni:
> > > On Mon, Aug 08, 2022 at 03:03:07PM -0400, Wietse Venema wrote:
> > >
> > > > All we need is a small bit of code that transforms SRV lookup results
> > > > into a list of [host]:port forms that the Postfix SMTP client already
> > > > understands.
> > >
> > > We have code to do MX lookups, it can be cloned to RFC6186 SRV lookups
> > > instead and then correctly implement the preference and weight logic!
> > >
> > > The transformation needs to sort by preference and randomise the weights
> > > with a given preference per the RFC.
> >
> > The result of MX lookup and sorting by preference is a linear list.
>
> Yes, precisely. Just noting that with SRV records the random weight
> sorting is slightly more tricky, but ultimately still an ordered list.
>
> > The result of SRV lookup and sorting by weight is also a linear
> > list. A this point I prefer a list in [host]:port form, simply
> > because it maximzes the reuse of all existing code.
>
> Yes. The main complication is that connection caching, TLS session
> caching and TLS policy are perhaps not quite right if we're not aware
> that the list of "[host]:port" pairs is actually a single logical
> destination, so the code would need to be integrated into smtp(8), and
> look mostly like MX resolution that returns "host:port" values for a
> single logical nexthop.
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?
SMTP_HOST_KEY uses newlines if I am not mistaken. And it is
completely hidden from the user interface.
Wietse
