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.
Since SRV-based server resolution would be a transport-wide behaviour,
and TLS session caching and connection reuse are already
transport-specific we'd just need to make sure that TLS policy
pertaining to port 25 delivery to a given domain is not confused with
submission to the same domain. One way to handle that is of course
to configure custom "smtp_tls_policy_maps" for the transport, but
another may be to tweak the lookup key. Thoughts?
Are keys along the lines of "domain:submission+srv" too clumsy?
--
Viktor.
