On 8/24/21 19:23, Viktor Dukhovni wrote:
On 24 Aug 2021, at 7:58 pm, Matt Corallo <ps...@mattcorallo.com> wrote:
May be worth mentioning here that, sadly, Postfix does not support MTA-STS
currently.
The one implementation at https://github.com/Snawoot/postfix-mta-sts-resolver/
will reduce security rather than increase it as dual-MTA-STS-DANE domains start
to appear[1]. Until then, because MTA-STS is deployed basically just by
Microsoft and Google, you can accomplish the same result by checking the MX is
outlook.com or google.com in a tls_policy_maps lookup daemon. By the point
MTA-STS matters in the slightest, even Microsoft should be enforcing DANE [2]
so there's probably not use bothering in any case.
[1] https://github.com/Snawoot/postfix-mta-sts-resolver/issues/67
[2]
https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=dnssec
MTA-STS is not presently worthy of support. Support is so thin, that
it is far simpler to just enable "secure" delivery to a small handful
of domains (gmail.com primarily), and be done. The policy can be
periodically updated by querying their MTA-STS record out of band.
The actual protocol is rather a kludge, and I am not inclined to write
code to support it.
Excuse me, I didn't mean to imply otherwise. The protocol is so comically stupid that it could only possibly have come
from a group still clinging to the idea that SSL certificates are somehow magically more trustworthy than the DNS
information that they use for their only source of truth, ignoring all practical experience from many years of deployment.
I was only noting that, for those who read the above and googled "postfix mta-sts", they should *avoid* running the one
result they find as it likely works well but breaks DANE, at least for the domains that will presumably eventually use
both DANE and MTA-STS.
