Re: [Asrg] Adding a spam button to MUAs

Steve Atkins <> Fri, 05 February 2010 04:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F14043A6C08 for <>; Thu, 4 Feb 2010 20:11:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.443
X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 I1iuI1cQsIbZ for <>; Thu, 4 Feb 2010 20:11:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4C0763A6B66 for <>; Thu, 4 Feb 2010 20:11:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 21E934F814C for <>; Thu, 4 Feb 2010 20:12:02 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
From: Steve Atkins <>
In-Reply-To: <>
Date: Thu, 4 Feb 2010 20:12:01 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Anti-Spam Research Group - IRTF <>
X-Mailer: Apple Mail (2.1077)
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 04:11:26 -0000

On Feb 4, 2010, at 7:57 PM, Chris Lewis wrote:

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

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.