ietf-asrg
[Top] [All Lists]

Re: [Asrg] Adding a spam button to MUAs

2010-02-05 06:28:05
On 05/Feb/10 05:12, Steve Atkins wrote:
On Feb 4, 2010, at 7:57 PM, Chris Lewis wrote:
 But if you do inband ARF directives, if the originator sets ARF strings, it 
needs to not DKIM that header ;-)

Agreed, but for originators only. Re-signing forwarders may well want to do that.

 I'd rather not burden the user with any configuration at all, and if you have 
to have the user do something, the lesser the better.  That isn't a big deal in 
environments where the users are running site-preconfigured MUAs (like us), but 
becomes an issue elsewhere, and you have to tell the user what to set it to.

It should be easy to specify how automatic configuration can determine that the principal mail domain can be trusted. Additional domains will have to be enabled manually, but that wouldn't be needed if forwarding were set up savvily.

 The advantage of MUA-only configuration is that you don't have to touch the 
MTAs at all to make it work.  Indeed, if you want to outsource your ARF 
handling, or the user wants to do them anyway, you only have to make your MUA 
TiS capable, no other changes required.  That may outweigh all other 
considerations.

+1

Also, if the failure mode is that the original sender of the email can cause 
feedback loop reports to be sent to any email address they like there aren't 
many real concerns.

First, confidential data. The only data that might be considered confidential 
is the contents of the original email (that's all there is in an ARF report 
other than a little metadata). The sender already has access to that, so it's 
pretty much a non-issue. (Most anyone can sign up for a feedback loop with 
consumer ISPs today, and there's not any obvious abuse of the data possible).

Second, use of the FBL for harassment. It's not a great channel for that, as 
even theoretically it can cause at most one email for each original email sent 
out. More realistically it's more like 1:100 or so, as pitching an email such 
that it'll get through someones spam filters to a recipient, but still be 
objectionable enough for them to hit the TiS button is tricky enough, and any 
mail sent to any ISP that was aware of this protocol (to the extent of 
overwriting or deleting the relevant header) wouldn't count. Less of an issue 
than return path or reply-to.

And that's about it. There's not really any need to "defend" against "forgery" 
at all.

The second statement is not strictly true, as multiple fields may be added at each hop.

Reports concerning bot-generated stuff should only be routed to the relevant connection provider. While some of them are apparently tackling the sanitization of their user bases, other LIR registrants may consider it a harassment to receive a stream of ARs, possibly at a random mailbox address of theirs, even if the data is good. They may want to opt out. A site policy may or may not allow that, but it shouldn't be an end-user decision.

IMHO the above is a rationale for letting MUAs send ARFs /only/ to the last (topmost) enabled authserv-id, unless explicitly overridden by user's configuration.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg