Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
That's the only way that makes sense. If the SMTP client expected
the server's cert to match the domain in the email address (the one
used to query for MX records), it would not be feasible to use the
same SMTP server to accept mail for multiple MX domains.
The problem with taking this approach is that you've now reduced the
security of your TLS session to the level of security of your DNS
lookup.
This is true in general. Just because you have a cert for a particular
domain does not mean you are authorized to accept mail for that domain.
Basically the email system, as part of its protocol definition, trusts
the DNS. If you don't have signed DNS records, there's a security hole.
It's always been there.
TLS simply wasn't designed to handle this case. If it were, there would
be a way to include additional certs of the form "domain X is authorized
to be an MX for domain Y" that were signed by domain Y, with a complete
certificate chain for domain Y leading back to a trusted CA _in addition
to_ the certificate chain for domain X.
Since we don't have that, what this means is that TLS by itself is of
limited applicability for email relaying. It does not guarantee that
the mail goes where it's supposed to go. Nor does it guarantee that
the traffic is not exposed to an eavesdropper. It's safer than sending
the mail in cleartext, but that's not the same thing as saying you
can trust it.
You have correctly identified the problem, though, namely that there's
no way prior to the TLS negotiation for the client to tell the server
which certificate it should present. HTTP has this same problem (thus
making it currectly impossible to use TLS on a server farm without
IP-based virtual hosts).
MX is not the same thing as virtual hosting.
Keith