On Fri, Jul 31, 2015 at 08:33:31AM -0700, Watson Ladd wrote:
> > Perhaps you're using the phrase "local resolver" in some novel way
> > that I don't understand. Why shouldn't an application trust
> > responses from 127.0.0.1:53? Those are in my view more trustworthy
> > than any library the application might attempt to use to perform
> > validation.
>
> Because the stub resolver on the box uses a recursive resolver on the ISP
> which doesn't send back the information required to determine validity, but
> a single bit.
I did say "127.0.0.1", not ISP iterator. I keep saying *local*
(perhaps I should have said "loopback") resolver, but nobody seems
to be reading the fine print. :-(
stub resolver <---> validating loopback iterator <---> Untrusted nameservers
If the *local/loopback* resolver happens to use the ISP as a
forwarder, that's not especially relevant, modulo the usual privacy
considerations.
I think we need to return the core subject of this discussion (high
level addrquery architecture). Authentication technology aside for
the moment, is the
MUA <---> MSA <---> MX host
transaction model acceptable or not? We can then talk about how
to authenticate each hop. If this is not acceptable, how does
addrquery get to the MX host? [ I'd be very reluctant to implement
a new MX host service which has many orders of magnitude more remote
clients than the existing MX host SMTP service. ]
This proposal looked promising because it piggy backs on the existing
SMTP backbone. If it abandons that, then my enthusiasm for it will
likely wane.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
