I see your point. But I suspect it illustrates a significant
limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume
that an IP address and port number are used by only one named service.
It's been awhile since I looked at the TLS protocol but I don't recall
any way for the client to say "prove to me that you are authorized to
provide the SMTP service associated with DNS name foo.com". or did I
just forget that feature?
This could be conceivably accomplished in two ways:
(1) By the application protocol (in this case SMTP) indicating
what server the client wanted to talk to.
I'm not sure how this would help. The client could say "I want to send mail
to domain XXX" in SMTP but a rogue server is going to say "you've come to the
right place". I suppose the client could say "prove you are the MX for domain
example.net" and the server could be expected to return a cert. But this has
backward compatibility problems.
(2) You could use the TLS domain name extension described in
draft-ietf-tls-extensions-06.txt, recently approved at
Proposed by the IESG.
I'll have to look at that; thanks for the ref.
Unfortunately, neither of these fixes solves the real problem,
which is that it's impractical for a relaying MTA to have a
a certificate for every host it might potentially receive
mail for, but that's what's required here.
I think you mean "every domain"; DNS names don't need to correspond to hosts
anymore (and often don't). I'm not sure why it's inherently impractical to do
this, especially if it were possible to have a single cert that covered
multiple domains (i.e. a statement of the form "mail.isp.com is a valid MX for
*.example.net" signed by example.net).
Keith