--On Tuesday, December 01, 2015 15:50 +0000 John Levine
<johnl@xxxxxxxxx> wrote:
>...
> The other is that there is no reasonable way for a CA to
> verify that the list of mail domains in a certificate is
> correct, which means that SNI wouldn't help. For example, one
> of my customers quarteracre.net has a few mailboxes at
> hostedemail.com. The usual CA validation wouldn't help, since
> there is nothing in the WHOIS for quarteracre.net or any of
> the other stuff that CA's normally check that tell you where
> their mail is.
>
> But there's no need to put this in the cert since RFC 6186
> already tells you:
>
> ;; QUESTION SECTION:
> ;_imaps._tcp.quarteracre.net. IN SRV
>
> ;; ANSWER SECTION:
> _imaps._tcp.quarteracre.net. 3600 IN SRV 1 1 993
> mail.a.hostedemail.com. _imaps._tcp.quarteracre.net. 3600 IN
> RRSIG SRV 8 4 3600 20160201000000 20151201054531 36633
> quarteracre.net.
> bCSLoiCnQcftwclKRbVXxP8c8nsX+TtgGpDCMQUR1AM+gjejgQ9bzU0v
> ZWKW44whg1mXwN79FwArNEZ/6/B77w4PVjvVBOWW6ZIhIq9AawIplUXU
> CdZ43dhNR/oVdFbp/g7H4h1U5+JJJWt4hqiCG7NEoRp7/jT0l4y4ndxW YBo=
>
> My suggestion would be to remove the email domain SRV-IDs from
> the certificates since they don't tell you anything useful,
> and to advise clients to use SRV and DNSSEC to get the name of
> the server if they want to be sure they have the right one. I
> suppose the CA could make the DNS checks, but that seems like
> a bad idea since certs are typically signed once a year, and a
> large mail system will add and drop client domains every day.
>...
John,
Insofar as I understand this (I've read the thread up to this
time, but the above seems most appropriate to which to reply),
there is one other issue:
If the DNS has
target.example.com. MX 0 smtp1.example.com.
MX 10 smtp2.example.net.
Then, first, if the message reaches smtp2.example.net and it
accepts that message (2yz responses to everything), it is under
no obligation to move it along using an SMTP connection to
smtp1.example.com. It does have an obligation to get the
message delivered (modulo the usual weasel-words), but not to
use SMTP to do so. More important, if the end user is going to
pick the message up via, say, IMAP, there is no requirement that
the IMAP server (or the mailstore) even be on the public
Internet, much less that it have a domain name, as long as the
IMAP Client MUA can be configured to find the relevant IMAP
server.
So it seems to me that even Harald's list of cases in which this
approach won't work and isn't applicable should be longer and
even more qualified. Put differently, while the numbers may be
large, it appears in practice that this approach is (even
potentially) applicable to a very small number of types of cases
and configurations and that the document should be very clear
about that, characterizing those cases in as much detail as
possible.
john