Re: [Asrg] We don't need no stinkin IMAP or POP, was Adding a spam button to MUAs

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@irtf.org
> http://www.irtf.org/mailman/listinfo/asrg
>