In Postfix 2.10, the default value of $parent_domain_matches_subdomains changed from:
parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,smtpd_access_maps To: parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,relay_domains,qmqpd_authorized_clients,smtpd_access_maps (Note the addition of "relay_domains".) Although this seemed like an innocuous change, it caused a temporary outage for us after we upgraded from 2.9.1 to 2.10. We have always used dot-prefix notation where necessary in our $relay_domains list. Specifically, we have listed ".example.com" in our $relay_domains parameter in our inbound SMTP firewall for years. But with the addition of "relay_domains" to this parameter upon upgrade, Postfix suddenly began deferring email destined to "sub.example.com" (denying relay) even though the dot-prefix was already there! The documentation for $parent_domain_matches_subdomains states: > A list of Postfix features where the pattern "example.com" also matches > subdomains of example.com, instead of requiring an explicit ".example.com" > pattern. This is planned backwards compatibility: eventually, all Postfix > features are expected to require explicit ".example.com" style patterns when > you really want to match subdomains. The documentation is vague about how Postfix behaves if the domain is already dot-prefixed, but I think it's reasonable that doing so should not change Postfix's behavior with respect to domain matching for relaying purposes. Does anyone disagree? Otherwise this seems like a bug. In the meantime we've manually removed "relay_domains" from the list to return to pre-2.10 behavior. Best regards, --Michael
