On 15/11/2025 05:54, Ömer Güven via Postfix-users wrote:
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.
Thanks for the heads up. For those running postfix-tlspol from
GhettoForge, I'm building 1.8.21 now.
Peter
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
