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

[Alessandro Vesely <[e-mail]>]

Michael Thomas wrote:
> John Levine wrote:
>> SRV has been around for 15 years, and it's intended for telling you
>> where a domain provides a particular service, which is what we're 
>> doing here.  Is there DNS software we care about that can support TXT
>> with a funny name but not SRV?
>
> I think that the dkim/spf experience is that anything beyond A and CNAME causes
> some dns providers out there to fail. Text does have the advantage that more providers 
> are supporting it because of dkim/spf. I don't think that srv has the same penetration 
> and/or use.... which is a pity because srv records are actually pretty nice in 
> theory.

Using SRV records would be consistent with similar email 
auto-configuration records defined in 
http://tools.ietf.org/html/draft-daboo-srv-email

It may be worth to note that such automatic configuration 
specification is arriving after years of manual configuration 
experience. Yet, it does not provide for automatically enabling the 
A-R field defined by RFC 5451 which, for security reasons, requires 
its field to be ignored "unless specifically enabled by the user or 
administrator after verifying that the border MTA is compliant". 
Possibly, such MTA compliance will eventually be flagged using DNS 
RRs as well, but A-R is not yet a widely deployed field.

Seeking auto-configuration for TiS buttons apparently clashes with 
the experience summarized above. Alex has described how flexible 
reporting flow could work, in a recent message. His description 
resembles the way spam complaints have been produced for many years. 
However, the reason why we want TiS buttons is that the volume of 
spam is so high that we cannot keep its pace unless we automate 
reporting. Even then, why do we want the mechanism for automatic 
reporting to also be automatically configurable?

The possible reasons that I can think of are as follows:

* users cannot determine whether their mailbox providers support
   spam reporting,

* MUAs cannot determine which is the last report-supporting MTA, if
   any, that received a given inbound message,

* most users already gave up reporting spam and won't resume unless
   presented with a fully automated tool, won't even go to the
   trouble of configuring it, or

* the reporting address isn't really fixed, and may vary without
   advice, independently of any other mailbox parameter.

Are there more? And which ones are more relevant?