Re: [Asrg] Adding a spam button to MUAs

"Chris Lewis" <> Fri, 05 February 2010 03:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68E833A6A28 for <>; Thu, 4 Feb 2010 19:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.421
X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.022, 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 HoVf5Q6SEm2e for <>; Thu, 4 Feb 2010 19:56:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 495203A6767 for <>; Thu, 4 Feb 2010 19:56:48 -0800 (PST)
Received: from ( []) by (Switch-2.2.0/Switch-2.2.0) with ESMTP id o153vXK23359 for <>; Fri, 5 Feb 2010 03:57:33 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 22:57:32 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 4 Feb 2010 22:57:32 -0500
Message-ID: <>
Date: Thu, 4 Feb 2010 22:57:21 -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: 05 Feb 2010 03:57:32.0923 (UTC) FILETIME=[584AB4B0:01CAA617]
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: Fri, 05 Feb 2010 03:56:50 -0000

Bart Schaefer wrote:
> On Feb 4,  4:18pm, Steve Atkins wrote:
> }
> } There's a subtle implication, which is that if you're stashing the
> } ARF consumer address in a header, and your MX isn't overwriting (or
> } stripping) that header, then it's possible that spam reports could
> } be sent to the preferred reporting address of someone further up
> } the delivery chain. I see this as an advantage, but it needs to be
> } mentioned.
> This is exactly the point I was making, over at the head of another
> sub-thread.  If a reporting address can come in from somewhere up the
> chain, then it can come in *forged*, and whatever software is going
> to interpret the address needs a defense against that.

> Numerous proposals for dealing with this (and arguments about why it
> isn't necessary, or in Rich's case, why it's irrelevant) have already
> been bandied about.

It happens ;-)

The basic thing is that either the MUA knows how to handle ARFs without 
relying on anything the mail stream (user config of where to send ARFs), 
or has to know that the message path supports abuse reporting (user 
configuration boolean switch), it can trust ARF directive[s] in the 
headers AND that the message stream HAS to take steps to destroy any ARF 
directives it doesn't want its downstream users to execute.

If either the above are true, you don't need to go to extremes to, say, 
cryptographically secure ARF directives and put all sorts of 
trust-evaluation gunk into the MUA.  Putting the latter in MUAs would be 
a big istake.

But if you do inband ARF directives, if the originator sets ARF strings, 
it needs to not DKIM that header ;-)

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.

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.