Hi, a postfix-tlspol user recently noted unexpected behavior when Postfix (starting with 3.10.5) uses the STS policy attribute mx_host_pattern for MX selection (enabled by default by smtp_tls_enforce_sts_mx_patterns and effective when QUERYwithTLSRPT method of postfix-tlspol is used, regardless of whether TLSRPT is enabled or not).
While reviewing this, I found that postfix-tlspol versions v1.8.15 through v1.8.20 contain a regression introduced during a refactoring change. What happened postfix-tlspol has produced correct mx_host_pattern attributes for MTA-STS/TLSRPT up to v1.8.14. However, a code refactor in v1.8.15 unintentionally applied a wrong wildcard-normalization logic to these attributes, stripping a leading „*“ from patterns such as „*.example.com“ to „.example.com“ (which is indeed correct, but only in the match= part). The refactor took this step too early in the code. This went unnoticed earlier because mx_host_pattern was previously used only for TLSRPT reporting. With Postfix 3.10.5+, these patterns are now used directly in the MX-selection path, making correctness essential. Impact With Postfix 3.10.5 or later, this can block delivery for domains with MTA-STS policies containing wildcard MX patterns (e. g. outlook.com) when QUERYwithTLSRPT method of postfix-tlspol is used instead of QUERY (former being recommended for Postfix 3.10+), regardless whether TLSRPT is enabled in Postfix or not. Fixed in v1.8.21 The regression is fixed in postfix-tlspol v1.8.21. Anyone running Postfix ≥3.10.5 with postfix-tlspol v1.8.15 - v1.8.20 should upgrade to v1.8.21 as soon as possible. Ömer aka DragonWork
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
