On Sat, 6 Feb 2010, John Levine wrote:
We've been talking about using DNS for some of the signalling. You
could specify a "_report.<mailstore hostname>" TXT record that specifies
the address (which isn't necessarily in the mailstore's domain) to send
it _and_ its very existence shows that the mailstore provider supports
the functionality (and thus the TiS button gets enabled).
Right. It would be a SRV record, but close enough.
I'm still worried about name overloading. Never in the history of POP
or IMAP has the name of the server been anything other than a handle
to the the IP address to which to connect. If your server has
multiple names, or no name, that has no effect on its operation.
Here's a concrete example, a customer of mine who uses the hosted mail
service at Tucows:
$ dig pop.philiphazan.com a
;; ANSWER SECTION:
pop.philiphazan.com. 294 IN CNAME
mail.philiphazan.com.cust.a.hostedemail.com.
mail.philiphazan.com.cust.a.hostedemail.com. 3594 IN A 216.40.42.5
$ dig imap.philiphazan.com a
;; ANSWER SECTION:
imap.philiphazan.com. 300 IN CNAME
mail.philiphazan.com.cust.a.hostedemail.com.
mail.philiphazan.com.cust.a.hostedemail.com. 3590 IN A 216.40.42.5
Their POP and IMAP servers have thousands of different names, one for
each hosting customer. If we do a DNS hack, each of those thousands
of customers has to add something to its DNS. If we do something
where the MDA adds a header, one software upgrade would make it work
for everyone.
This is a common way to set up a mail system for hosting services. So
you tell me, which approach is "simpler"?
1) If you have thousands of email domains, then perhaps they are generated
mechanically, and a small change of code would create thousands of MX
records.
2) There is always the wildcard, at least in Bind, which would make it a
one line change.
3) The existence of a handful of sites where implementation would be work
is hardly a reason to make additional works for millions of sites with
a single domain.
4) The resistance to adoption will come chiefly from MUA vendors. MTA
operators may be lax in using the information, but at least some
of them will process the submissions. Getting even a single widely
used MUA to adopt this would be a major accomplishment.
Daniel Feenberg
R's,
John
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg