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... ]
> > >
> >
> >
>
