Viktor Dukhovni:
> 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:
Nevertheless, big news! Congratulations and thanks for pushing.
Wietse
> 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.
>
