Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <vesely@tana.it> Tue, 02 February 2010 11:57 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 E66BE3A6918 for <asrg@core3.amsl.com>; Tue, 2 Feb 2010 03:57:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.724
X-Spam-Level:
X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[AWL=-0.161, 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 TgCS3rIfAHnz for <asrg@core3.amsl.com>; Tue, 2 Feb 2010 03:57:11 -0800 (PST)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 0D94B3A692D for <asrg@irtf.org>; Tue, 2 Feb 2010 03:57: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; Tue, 02 Feb 2010 12:57:46 +0100 id 00000000005DC035.000000004B68133A.00000445
Message-ID: <4B68133A.6040104@tana.it>
Date: Tue, 02 Feb 2010 12:57:46 +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: <20100201145903.30670.qmail@simone.iecc.com> <3741B85B916D847C703F2724@lewes.staff.uscs.susx.ac.uk> <A50C736E-EE14-4213-B99D-DD58C669FDAC@blighty.com> <100201092326.ZM5487@torch.brasslantern.com> <4B67ADC2.4080204@nortel.com>
In-Reply-To: <4B67ADC2.4080204@nortel.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: Tue, 02 Feb 2010 11:57:12 -0000

On 02/Feb/10 05:44, Chris Lewis wrote:
> As long as the client "knows" whether its front ends support this
> functionality (might be config value of administrative domain), and
> ignores them if it isn't, the security issues are fairly limited.
>
> Still need DKIM?

An ARF received at a domain's "abuse@" mailbox may arrive from an 
authenticated client, and it won't be DKIM-signed in that case. 
However, the abusive message being reported may have signatures.

Or it may arrive from a third party. A third party presumably rewrites 
both the boilerplate and the machine-readable parts, and I would 
expect it DKIM-signs them. An MTA should only receive reports where 
the Reported-Domain field indicates its own domain. Generic operators 
may also receive reports that they are supposed to "forward" 
--possibly rewriting and signing the first two parts in turn.

> If the sender is "permitted" to insert them, for them to mean much, you
> get into the same issues as end-to-end DKIM on email has. You know that
> the signature verifies or not, but you still don't know whether you want
> to trust the information.

Perhaps an MTA should verify on its own that an AR is correct. For 
authenticated clients, it may check its receive log. For reports 
routed by third parties, it may also verify its own signatures.