Let’s say i have these records:
- A reverse.somedomain: 127.0.0.1
- A mail.somedomain: 127.0.0.1
- A mail.mailserverdomain: 127.0.0.1
- MX somedomain: mail.somedomain
- PTR 127.0.0.1: reverse.somedomain
A MTA connects
mail.somedomain for delivering mail to
somedomain and gets a certificate for
mail.mailserverdomain presented, and the MTA presents its hostname as
Is this a valid TLS session or would this mean a certificate for a wrong hostname (expecting
Surprise! For a TLS negotiation with a mail server, typically the subject name is not checked at all. Much of the encryption between mail servers is entirely opportunistic, using only self-signed certificates, often with a subject name of localhost.
Unfortunately, it’s not really possible to do much better than this, as it is possible to MitM the connection and prevent the encryption negotiation from ever taking place. And it’s not possible to prevent that attack until DNSSEC (or an equivalent) is fully deployed and everyone requires proper certificates of everyone else. This is unlikely to happen before we retire.
If your email must be encrypted end to end, you’ll need to do it yourself.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.