wietse-postfix
commented
2 months ago DragonWork:
In reference to https://github.com/Snawoot/postfix-mta-sts-resolver/issues/107
@wietse-postfix To clarify, how is the implementation supposed to output the policy?
As part of the response:
tls-security-level ... { policy_string = version: STSv1} { policy_string = mode: enforce } ....Simply append the comma-separated new parameters to the space-separated policy? That's a little confusing. Is it backwards compatible?
Can you provide a full example using the gmail.com policy?
MTA-STS policy of gmail.com:
version: STSv1 mode: enforce mx: gmail-smtp-in.l.google.com mx: *.gmail-smtp-in.l.google.com max_age: 86400This currently evaluates to:
secure match=gmail-smtp-in.l.google.com:.gmail-smtp-in.l.google.com servername=hostnameYour new TLSRPT feature wants us to do the following:
secure match=gmail-smtp-in.l.google.com:.gmail-smtp-in.l.google.com servername=hostname policy_type=sts policy_domain=gmail.com policy_ttl=86400 { policy_string = version: STSv1 }, { policy_string = mode: enforce }, { policy_string = mx: gmail-smtp-in.l.google.com }, { policy_string = mx: *.gmail-smtp-in.l.google.com }, { policy_string = max_age: 86400 } mx_host_pattern=gmail-smtp-in.l.google.com, mx_host_pattern=.gmail-smtp-in.l.google.com
Almost. The "mx_host_pattern=.gmail-smtp-in.l.google.com" looks incorrect.
According to RFC 8460, an mx_host_pattern is a pattern from the STS policy, so I expect that your example should be "mx_host_pattern=*.gmail-smtp-in.l.google.com".
But the mixture of comma- and space-separated entries doesn't feel right and intuitive. Please verify.
The smtp_tls_policy_maps parser does not care if you specify comma, space, or both. See https://www.postfix.org/postconf.5.html#smtp_tls_policy_maps
"The lookup result is a security level, followed by an optional list of
whitespace and/or comma separated name=value attributes that override
related main.cf settings."The smtp_tls_policy_maps documentation does not use commas in https://www.postfix.org/postconf.5.html#smtp_tls_policy_maps.
I'll update the TLSRPT documentation to be consistent with the existing examples for smtp_tls_policy_maps.
I just releases a non-production Postfix release. I recommend waiting until I have tested it (i.e. it iis no longer 'non-production').
Wietse
In reference to https://github.com/Snawoot/postfix-mta-sts-resolver/issues/107
@wietse-postfix To clarify, how is the implementation supposed to output the policy? Simply append the comma-separated new parameters to the space-separated policy? That‘s a little confusing. Is it backwards compatible?
Can you provide a full example using the gmail.com policy?
MTA-STS policy of gmail.com:
This currently evaluates to:
secure match=gmail-smtp-in.l.google.com:.gmail-smtp-in.l.google.com servername=hostnameYour new TLSRPT feature wants us to do the following:
secure match=gmail-smtp-in.l.google.com:.gmail-smtp-in.l.google.com servername=hostname policy_type=sts policy_domain=gmail.com policy_ttl=86400 { policy_string = version: STSv1 }, { policy_string = mode: enforce }, { policy_string = mx: gmail-smtp-in.l.google.com }, { policy_string = mx: *.gmail-smtp-in.l.google.com }, { policy_string = max_age: 86400 } mx_host_pattern=gmail-smtp-in.l.google.com, mx_host_pattern=*.gmail-smtp-in.l.google.comBut the mixture of comma- and space-separated entries doesn‘t feel right and intuitive. Please verify.