Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <vesely@tana.it> Fri, 05 February 2010 12:27 UTC

Return-Path: <vesely@tana.it>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C81428C115 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 04:27:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.631
X-Spam-Level:
X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+oH3H9sFrtS for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 04:27:10 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 39B6328C125 for <asrg@irtf.org>; Fri, 5 Feb 2010 04:27:10 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 05 Feb 2010 13:27:59 +0100 id 00000000005DC033.000000004B6C0ECF.00000528
Message-ID: <4B6C0ECF.9080906@tana.it>
Date: Fri, 05 Feb 2010 13:27:59 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: asrg@irtf.org
References: <20100204232046.53178.qmail@simone.iecc.com> <4B6B5F78.3070607@nortel.com> <7AC9CB85-1F82-4FD8-8411-F45E74EE6A59@blighty.com> <100204185834.ZM11044@torch.brasslantern.com> <4B6B9721.3010802@nortel.com> <7C87C226-CF1A-4E35-9D35-902306CDE3C2@blighty.com>
In-Reply-To: <7C87C226-CF1A-4E35-9D35-902306CDE3C2@blighty.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Adding a spam button to MUAs
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2010 12:27:11 -0000

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.