Re: [Asrg] We really don't need no stinkin, was MUA spam button
2010-02-06 16:34:56
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 hardly matters, since whichever it is, you cannot count on it
being consistent or even known to the server operator.
Anyway, since this is supposed to be a research group, I did a little
research to see what other mail hosting providers do:
Rackspace: use their name
Fusemail: per-domain CNAME
Everyone.net: use their name
Godaddy: unclear, examples all say "use your server name"
Yourdomainhost: use their name
runbox: use their name
host45.com: per-domain name (unclear whether CNAME or A)
It's certainly not universal to use per-domain names, but it's not an
unusual edge case either.
Here', we have a direct -- single 'hop' -- trust-based relationship. Much
simpler.
And it has the same problem as SPF. SPF is based on the false premise
that all mail is sent directly from the originating to the receiving
server, and the equally false premise that all mail is sent from servers
managed by the owner of the bounce address domain (or, for Sender ID, the
false premise that it's servers managed by the From: line domain.)
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.
In both cases, although the premises are true often enough to be
superficially plausible, they fail in significant numbers of cases, and
when they do, you're stuck with ugly complex kludges, or you just give up.
The proposals for Authentication-Results: seem to have workable ways to
detect fake headers. What do they know that we don't?
R's,
John
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Asrg] We don't need no stinkin IMAP or POP, was Adding a spam button to MUAs, (continued)
- Re: [Asrg] We don't need no stinkin IMAP or POP, was Adding a spam button to MUAs, John Levine
- Re: [Asrg] We don't need no stinkin IMAP or POP, was Adding a spam button to MUAs, Chris Lewis
- Re: [Asrg] We don't need no stinkin IMAP or POP, was Adding a spam button to MUAs, John Levine
- Re: [Asrg] We don't need no stinkin IMAP or POP, was Adding a spam button to MUAs, Dave CROCKER
- Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M, John R Levine
- Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M, Dave CROCKER
- Re: [Asrg] We really don't need no stinkin, was MUA spam button,
John R. Levine <=
- Re: [Asrg] We really don't need no stinkin, was MUA spam button, Dave CROCKER
- Re: [Asrg] More reasons you can't overload POP and IMAP server names, John Levine
- Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M, Ian Eiloart
- Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M, Peter J. Holzer
- Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M, Ian Eiloart
- Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M, John Levine
- Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M, Ian Eiloart
- Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M, Bart Schaefer
- Re: [Asrg] who gets the report, was We really don't need, John Levine
- Re: [Asrg] who gets the report, was We really don't need, Seth
|
|
|