Today, Microsoft announced plans to implement SMTP DANE TLS in Office365
"Exchange Online":
https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494
this is not live yet, the implementation will be in two stages:
The first phase will include only outbound support (mail sent outbound
from Exchange Online) and we aim to enable this by the end of the
calendar year 2020.
The second phase will add inbound support for Exchange Online and we
plan to enable that by the end of 2021. For both of those phases,
corresponding TLS-RPT support will be provided.
The relevance of this to the Postfix community is:
- If you are already publishing DANE TLSA records for your MX hosts,
now is a good time to make sure that these are not neglected or
managed poorly. Please read:
https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17
https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
in particular, make sure that your TLSA RRset is *monitored* and
any dicrepancies betweent the DNS and your live certificate chain
are brought to your attention for remediation in a timely manner.
With monitoring under control, make sure that your certificate
rollover practices are robust enough to avoid even transient
problems as a result of changing the cert/key *before* the
corresponding *new* TLSA RRs are published (along with records
matching the *current* chain).
Also, just in case, locating a working technical contact for your
domain should not require crystal ball gazing, or some form of
voodoo. Please consider publishing an RFC8640 TLS-RPT address,
and an working contact address in your SOA record. If all else
fails, have a working postmaster mailbox that is actually read.
- If you don't already publish TLSA records, that's fine, and I
don't encourage doing it "as a fashion statement". Don't do it
unless you take the time to do it well (see above). That said,
please consider adopting DNSSEC and DANE.
Considerable work has gone into BIND 9.16 to make key management
easier, with BIND now able to not only automatically resign your
zone, but also do automated rollover of signing keys. This may
be a good time to dip your toes in the water, and learn how to
deploy DNSSEC.
As always, monitor what you deploy, unmonitored infrastructure
should be an oxymoron.
--
Viktor.
