Conversation
If only it had a hall of shame for senders that deliver to wrong...
1
Replying to
By all means, build a tool that does this. Instructions and code are linked at the bottom. This tool doesn't, because that would make it less useful as a tool (i.e. knowing where you stand without social risk).
2
1
To clarify: I think both are useful (with & without the HoS). I built one. I'll be glad to see the other built as well.
1
1
I think the use would primarily be users checking if their mail providers are secure. As a nice example, ProtonMail claims to support DANE but someone in #grapheneos tested with havedane.net and ProtonMail happily delivered a message to wrong.havedane.net...
2
1
It would also be nice to have a 4th test using a domain with a valid DANE record but without DNSSEC. It's possible to enable DANE verification without DNSSEC, at least with Postfix, and ideally that kind of misconfiguration would be detected.
3
1
While it's a misconfiguration per the standards, it's still far better than not having DANE at all. MITM then requires ability to intercept both connection and DNS channel.
1
Yeah, it's so easy to just build it with DNSSEC support and turn on a single additional option though. I think it would be pretty easy to accidentally enable DANE support without turning on DNSSEC. Both should really be enabled by default, since it doesn't break compatibility.
The risk is a false sense of security if resolv.conf lists at least one non-loopback resolver. The portable C-library DNS resolver routines don't expose any getters or setters for the nameserver list, so Postfix is blind to the security of the configured resolvers. Caveat admin.