On Feb 5, 2010, at 9:59 AM, Daniel Feenberg wrote:
On Fri, 5 Feb 2010, Steve Atkins wrote:
On Feb 5, 2010, at 4:09 AM, Daniel Feenberg wrote:
I haven't been following this thread very closely, but why not just
establish a standard role account on the MUAs designated POP or IMAP
server? Such as arf(_at_)pop(_dot_)example(_dot_)com? It effectively
"preconfigures" the MUA since "arf" is standard and "example.com" is
already known to the MUA. The less configuration the better, I think.
POP and IMAP servers don't receive email. If you're planning on mandating
that all POP or IMAP servers listen on port 587, that's a fairly big
requirement.
Mail to arf(_at_)pop(_dot_)eample(_dot_)com may go to the host named
example.com, or it may go to a host of any other name given in the MX
statement for example.com. There is no requirement that pop.example.com host
an MTA at all. Am I missing something or are you teasing me?
I was asking for clarification - if you read the next sentence, you'll see me
doing that, even mentioning MX records - as you suggested that the role account
be on the designated POP or IMAP server.
Furthermore, there can be no expectation that all email domains will support
this protocol - so my expectation is that all email domains that wish to
support this protocol for users receiving mail from pop or
imap(_at_)example(_dot_)com must have an MTA somewhere that can accept mail
for arf(_at_)[pop|imap}.example.com. If there is a domain somewhere that
wishes to support the protocol, but does not wish to use the naming
convention, then they would be left out in the cold. I don't see that as a
very big concern.
What if they wish to use the naming convention, but do not wish to use the
protocol?
A not unheard of setup for a vanity domain is for all traffic to be served at
"example.com" - web, email, everything.
So there's a DNS record "example.com MX 10 example.com", and a POP3 or IMAP
server listening on example.com[1].
If the MUA uses the existence of an MX record for the hostname of the POP or
IMAP server to decide whether to enable the "TiS" button (an obvious thing to
do) then in that case it will be enabled.
If the user hits the "TiS" button, then it'll either cause a rejection, a
deferred bounce or (if it's a catch-all domain) deliver the report back to the
users inbox.
This violates the UI principle of least surprise, and is part of what I was
talking about when I said "namespace pollution".
[1] It may also be listening on imap.example.com, mail.example.com,
pop3.example.com and www.example.com, all at the same IP address. As IMAP and
POP3 are not name-based protocols, all of these will work. So the end user
could put any of these in to their MUA as their IMAP server, and mail will work
just fine. Automatic discovery may find one of these and not another, depending
on probe order. So if you're relying on the MUAs IMAP server setting as a key,
it's not that simple.
The desire to eliminate all naming conventions strikes me as pointless - they
are widespread and quite helpful in my experience. From localhost to
127.0.0.1, to postmaster and abuse what is the downside? Someone may wish to
use "localhost" as a hostname? Did they miss the IETF meeting? Then they are
out of luck. In any case, at somepoint there has to be a convention, all the
protocol can do is add levels of indirection.
Daniel Feenberg
Or are you suggesting something MXish or SRVish (which isn't implausible,
though it's got the usual namespace pollution problems to dodge)?
Cheers,
Steve
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg