I wonder how long it'll be before large companies require DNSSEC (and verify) + TLS for delivering email 2FA codes.
My guess is never, despite the relative ease that those codes can be spied upon.
Conversation
Replying to
Need TLSA records (DANE) in addition to DNSSEC to provide TLS authentication for email.
MTA-STS is a much weaker approach. Requires DNS records and an HTTPS web server which it uses to fetch an mta-sts.txt file similar to dynamic (no preload) HSTS if you only used http:// URLs.
2
9
Replying to
Yes, I was thinking of mentioning TLSA records, but so many people don't even do the few I mentioned. (I have TLSA records deployed for my mail server, but I don't know if my MTA will check and verify the TLSA record?).
2
Replying to
Enabling it for Postfix simply requires setting up unbound as your resolver and then enabling 2 configuration options:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
Enables opportunistic dane where it uses it when there are TLSA records and prevents downgrades.
It's easy to set up for both receiving (single DNS record) and sending (2 painless configuration options). You can use havedane.net to test whether you have working DANE verification for sending mail.
MTA-STS is a pain to set up inbound, and outbound is far worse.
1
3
MTA-STS requires you set up a web server for every single domain receiving mail, not just your MX domains, although you do probably also need it for your MX domains since that's where error emails are normally set as originating. We have one MX domain (mail.grapheneos.org),
1
3
Show replies
Replying to
Nice, I may have to finally switch after figuring out how hard it is to deploy w/ my current MTA.
1
1
Replying to
Postfix has really good support for DANE and it's fairly easy to set up proper SPF / DKIM / DMARC verification to prevent mail spoofing from domains with an enforcing DMARC policy. We partially publish our configs at github.com/GrapheneOS/mai.
1
1
3
Show replies
And of course making sure to list only loopback addresses in /etc/resolv.conf or wherever your system stores resolver settings.
I hope to revamp opportunistic DANE support in Postfix 3.8, making the residual security policy for non-DANE MX hosts more flexible than fixed "may".
1
1
2
That would be nice. We enforce TLS for receiving mail for mail.grapheneos.org already and we had never received a non-spam email without TLS before we started doing it. Currently can't easily do it for sending mail since we use opportunistic dane and it's the same setting.