Wietse Venema: > Tomas Korbar: > > Hi guys, any update on this? > > Microsoft autoconfiguration uses WKS for other services: submission,
Of cour that's SRV not WKS. > smtp, not just smtps. Any suggestions for handling that in Postfix > without hard coding all those names? I'm thinking of a table-driven thing, with the SRV prefix on the left, returning a list of main.cf overrides. The default setting could be: smtp_srv_options = regexp:{ { /^_submission._tcp\./ srv_resolution_allowed=yes, tls_wrappermode=no } { /^_smtps._tcp\./ srv_resolution_allowed=yes, tls_wrappermode=yes ...} ...and so on... This would allow temporary override of smtp_srv_resolution_allowed and smtp_tls_wrappermode settings. Would that be usable? Or maybe no need for regexps, and have just a list of prefixes on the left? smtp_srv_options = inline:{ { _submission._tcp srv_resolution_allowed=yes, tls_wrappermode=no } { _smtps._tcp srv_resolution_allowed=yes, tls_wrappermode=yes ...} ...and so on... That may be easier to configure. I'm not asking you to implement this! Wietse > > > On Thu, Sep 8, 2022 at 3:53 PM Wietse Venema <wie...@porcupine.org> wrote: > > > > > > Tomas Korbar: > > > > Hi guys, > > > > I created a new version of this feature which does not include > > > > changes in connection management code. > > > > Furthermore this new version adds configuration parameter > > > > "-o smtp_srv_resolution_allowed=yes" which enables it, so > > > > only users interested in SRV resolution can use it. > > > > > > > > Thanks for any review or help that you can provide. > > > > > > Thanks, I'll check it out. > > > > > > Wietse > > > > > > > On Tue, Aug 9, 2022 at 1:53 PM Tomas Korbar <tkor...@redhat.com> wrote: > > > > > > > > > > Hi guys, > > > > > Thanks for your opinions and hints. I will try to come up with > > > > > a implementation that does not involve changes in > > > > > Postfix connection management code. smtp process was > > > > > the first place where I thought that this feature could be > > > > > implemented. > > > > > > > > > > On Tue, Aug 9, 2022 at 11:56 AM Wietse Venema <wie...@porcupine.org> > > > > > wrote: > > > > > > > > > > > > Viktor Dukhovni: > > > > > > > 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. > > > > > > > > > > > > Seriously, this is MUA submission, we don't need to optimize > > > > > > connection reuse for that. > > > > > > > > > > > > > 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. > > > > > > > > > > > > Some kind of grouping metadata can take care of that. > > > > > > > > > > > > Wietse > > > > > > > > > > > > [ Attachment, skipping... ] > > > > > > > >