Tony Finch wrote:
On Mon, 22 Aug 2005, Claus Assmann wrote:
However, in some cases you don't want to speak to a particular
"personality" (virtual host) of a server but to several of them
because you figured out that <A(_at_)Z> and <B(_at_)Y> are both served by
the same host. This is one of the problems when I looked into
session reuse (as well as sending multiple RCPTs in a single
transaction): under which circumstances is it ok to do that?
This is why the distinction between hostnames and mail domains is
important. It is the *host* that you are talking to (not a mail domain) so
that is what a TLS cert should verify. That host should be prepared to
handle any recipient address at any mail domain for which it is the
advertised MX target, regardless of other recipients of the message or
other messages in the session. Virtual hosts, as in web server
terminology, usually don't make sense for email because MX records provide
the necessary indirection.
i think that could be an overrequirement. the q is not who is doing
something it is who is responsible, and thats the domain and not a
particular host in the domain.
e.g. im running a little gateway with wlan hostapd with eap-tls here and
ive issued certificates for unqualified hostname auth for hosts to the
ap over CN's. the certs are restricted to this purpose but if i had
included fully qualified hostnames to the CA's cert and client certs and
one funny guy gets the idea enabling ipsec auth to the outside inet
(without the NAT router hopefully breaking it) then the domain would be
responsible and authenticated. so a single host with his own
*unqualified name* hostcert cant authenticate for a domain.
certificates for inet can/must contain the DN (domain) and CN (host)
with wildcards if you wish.