Re: [Asrg] Adding a spam button to MUAs

"Chris Lewis" <> Tue, 02 February 2010 18:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FDF128C0CF for <>; Tue, 2 Feb 2010 10:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.411
X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oNDNkAvB+FyJ for <>; Tue, 2 Feb 2010 10:01:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 467313A6964 for <>; Tue, 2 Feb 2010 10:01:19 -0800 (PST)
Received: from ( []) by (Switch-2.2.0/Switch-2.2.0) with ESMTP id o12I1qb00745 for <>; Tue, 2 Feb 2010 18:01:52 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 13:01:51 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 2 Feb 2010 13:01:51 -0500
Message-ID: <>
Date: Tue, 2 Feb 2010 13:01:42 -0500
From: "Chris Lewis" <>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Lightning/0.9 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Feb 2010 18:01:51.0783 (UTC) FILETIME=[CC160B70:01CAA431]
Subject: Re: [Asrg] Adding a spam button to MUAs
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Feb 2010 18:01:20 -0000

Alessandro Vesely wrote:
> 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.

I was referring on the _client_ trusting the header its front end would 
have inserted to indicate where/how to send a report.  If we only add 
these headers at the receiving end, the receiving end zaps all prior 
instances of the TiS header and inserts its own, and the client knows 
that the receiving end inserts this header, then there's only the issue 
of the client roaming somewhere else and getting a forward.

Your above appears to be on the abuse@ mailbox (or whatever) deciding to 
trust the report it got from the client.  That's a different affair.

>> 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.

That might be an option, but that ties the abuse@ rather more intimately 
and automatically to the MTAs (and their logs etc) than you'd like.

I wouldn't necessarily want the MTA to handle abuse@ reports.  Eg: you 
have multiple MTAs.  You want a central report point, and let _it_ know 
how to propagate the choices it's going to make, and don't insist that 
it necessarily has logs (or logs timely enough) to do real-time 
verifies.  Best not to design it with that much close-coupling _not_