On 2/6/2010 2:34 PM, John R. Levine wrote:
Offhand, your model seems to be confusing public domain names -- such as
what others send email to -- from internal names, such as what is used
between the hosting service and their direct clients.
Sorry, I don't understand this. Would you call the host name of the POP or
IMAP server configured into the user's MUA a "public" or an "internal" name?
It's an internal name.
It's not for use by anyone out there in the open
Internet, the way an MX domain name is. It's for use by clients with whom the
operator has an established relationship. That's internal.
> It hardly matters, since whichever it is, you cannot
count on it being consistent or even known to the server operator.
Actually, it matters quite a lot. Pre-arranged relationship vs. no prior
relationship carry masses of differences. This becomes merely one more.
Anyway, since this is supposed to be a research group, I did a little
research to see what other mail hosting providers do:
You left out yahoo, google, comcast, att, and the broad range of non-US-based
major ISPs. I believe the list I just provided constitutes the vast majority of
public mailboxes and I believe they all are "use their domain".
The fact that there is more than one provider that suits your scenario does not
automatically remove it from the edge.
And for reference, you are postulating that the DNS-based query is hugely
expensive for those providers using your scenario, but I'm not convinced that it
does.
They have tailored software to support the scenario: they have to, to get the
name-and-address mappings and logins and permissions to all work. There's a
considerable administrative engine behind that scenario and I suspect that
modifying that engine to support this additional function is a long, long way
from onerous.
Here', we have a direct -- single 'hop' -- trust-based relationship. Much
simpler.
And it has the same problem as SPF.
You appear to be postulating that the DNS query would fail. Please explain how
and in what cases.
DNS queries have significantly different characteristics from multi-hop email
relaying, so I do not see how the problem SPF experience applies to a DNS query.
You're proposing a system based on the false premise that all mail is
delivered via POP and IMAP, and the equally false premise that all POP and
IMAP servers are referred to by a single name known to the server operator.
(FWIW, I didn't propose this. I'm merely supporting it...)
The proposal does not know or care about the retrieval protocol. What it cares
about is that the retrieval is based on access using a domain name. If it has a
domain name for retrieval, then this scheme is reasonable.
I suspect that the use of detached MUAs (thunderbird, outlook, etc.) based on
Internet applications employs a domain name for something like six sigmas of the
Internet user population (that uses MUAs.)
But FWIW, it's ok to specify a mechanism that works for "only" those folk who
use POP or IMAP...
It's ok for a percentage of cases to need a different mechanism.
The proposals for Authentication-Results: seem to have workable ways to
detect fake headers. What do they know that we don't?
I'm not aware of its having enough experience to report back on the trust
boundary enforcement issues.
I suspect when there is reasoned discussion based on experience, we'll also find
some important differences in the architecture it is used within, differing in
one or another important ways from the architecture this mechanism is being
targeted for.
But perhaps not.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg