mirror of
https://github.com/KumoCorp/kumomta.git
synced 2026-09-05 00:00:45 +00:00
Wez Furlong
41be60dfce
refs: https://github.com/KumoCorp/kumomta/issues/484 Briefly, the issue is that if some random domain that shares MX records with another (eg: someone is using google apps or icloud for their vanity domain) publishes a broken MTA-STS policy that requires eg: cloudflare MX hosts then because we roll up by site name, that broken MTA-STS policy bleeds into all the other domains that share those MX records. The resolution is simple, but is technically a breaking change. Moving the policy resolution to happen during site_name resolution allows us to resolve both per-domain things at the same and have the MTA-STS policy amend the effective set of MX hosts. The output of that is then used for site_name aggregation/rollup. The consequence of this is quite nice: an MTA-STS policy that is more restrictive than the full set of MX hosts now prevents delivering to any of the excluded hosts, and a totally broken policy that prevents all of its MX hosts is now completely undeliverable and will produce transient failures. The downside is that for users that had previously disabled mta-sts in their default shaping block, they will need to change a different config option to continue to prevent MTA-STS from being consulted. One example of this that I recall is that one user's network posture prevented MTA-STS from making HTTPS requests to fetch the policy. Another user just wanted to cut out the additional DNS traffic. Those use cases require altering the new kumo.dns.set_mta_sts_enabled enabled to false during `init`.