On Sat, May 28, 2022 at 03:09:40PM +0200, Joachim Lindenberg wrote:
> I don´t get why defining a different transport per domain should be
> easier than defining a tls policy per domain, and my configuration is
> mostly automated anyway.
Not *per-domain*, per TLS security level. All domains that want "may"
would use the same transport. This avoids the need to list the domain
in two separate tables (transport and TLS policy). Of course you can
use the TLS policy table if you prefer.
> figuring out adequate configuration. If I get your message right, the
> [] are essential to match nexthop? I double checked and I didn´t have
> [] in my route so far.
Instead of asking me to remember the details, check the documentation I
wrote when the feature was designed and implemented:
http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps
...
The TLS policy table is indexed by the full next-hop destination, which
is either the recipient domain, or the verbatim next-hop specified in
the transport table, $local_transport, $virtual_transport,
$relay_transport or $default_transport. This includes any enclosing
square brackets and any non-default destination server port suffix. The
LMTP socket type prefix (inet: or unix:) is not included in the lookup
key.
Only the next-hop domain, or $myhostname with LMTP over UNIX-domain
sockets, is used as the nexthop name for certificate verification. The
port and any enclosing square brackets are used in the table lookup key,
but are not used for server name verification.
When the lookup key is a domain name without enclosing square brackets
or any :port suffix (typically the recipient domain), and the full
domain is not found in the table, just as with the transport(5) table,
the parent domain starting with a leading "." is matched recursively.
This allows one to specify a security policy for a recipient domain and
all its sub-domains.
...
The "either" in the first of the paragraphs above describes what the
full nexthop destination can be, it is not a suggestion that you can use
either the recipient domain or the transport nexthop. So the recipient
domain is only applicable when not preempted by a transport:nexthop
override, be it from the transport table or "default_transport",
"relay_transport", ...
Whatever nexthop you use in the transport table, must be the verbatim
key in the TLS policy table. Only when that nexthop is free of
enclosing "[]" and ":port" suffix is parent domain policy considered.
If you find some unofficial HOWTO that says otherwise, the HOWTO is
mistaken.
--
Viktor.
