In message <alpine.OSX.2.11.1512031709300.7548@xxxxxxx>, "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@xxxxxxx