> > 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