In message
<alpine(_dot_)OSX(_dot_)2(_dot_)11(_dot_)1512031709300(_dot_)7548(_at_)ary(_dot_)lan>,
"John R Levine" writes
:
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.
I think the problem that we're trying to address here is setting up a MUA
and wanting to ensure that it's talking to the correct SUBMIT, POP, and
IMAP servers. You're right that there's all sorts of private networks
with mysterious naming, but every smartphone has an MUA that usually does
SUBMIT and IMAP, so it would be nice if the phone's MUA could reliably
configure itself with minimal help from the user.
Verifying SMTP servers seems like a much easier problem -- the MX records
are signed with DNSSEC, and the SMTP server presents a certificate with
the right name, either signed by a mutually satisfactory CA or verified by
DNSSEC signed TLSA.
And publishing and verifying the submit servers with SRV is just
as easy with DNSSEC. It's trying to make it work without DNSSEC
that is hard.
Apple, Google and Microsoft could be supplying a DNSSEC aware stub
resolver in their products today if they wanted to. They could be
supplying the root's trust anchor like they supply CA bundles to
that stub resolver. Then all the products running on those platforms
would have access to DNSSEC without having to roll their own
validator.
Mark
R's,
John
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org