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 >
