Re: [Asrg] Adding a spam button to MUAs

Steve Atkins <steve@blighty.com> Fri, 05 February 2010 17:32 UTC

Return-Path: <steve@blighty.com>
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 576653A6F52 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 09:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.443
X-Spam-Level:
X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9UTreQiDLSHb for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 09:32:50 -0800 (PST)
Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 6C87B28C1EA for <asrg@irtf.org>; Fri, 5 Feb 2010 09:32:50 -0800 (PST)
Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 979EC807A5 for <asrg@irtf.org>; Fri, 5 Feb 2010 09:33:41 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1077)
From: Steve Atkins <steve@blighty.com>
In-Reply-To: <4B6C52F1.20703@nortel.com>
Date: Fri, 05 Feb 2010 09:33:41 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <34C1CF19-375A-44C8-BBB4-7A7EE689F143@blighty.com>
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> <4B6C52F1.20703@nortel.com>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
X-Mailer: Apple Mail (2.1077)
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 17:32:52 -0000

On Feb 5, 2010, at 9:18 AM, Chris Lewis wrote:

> Steve Atkins wrote:
> 
>> 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.
> 
> You're assuming that only the UA would generate ARFs.

No.

I'm assuming that only the MUA would generate human triggered reports. (And please don't refer to them as "ARFs" as that's... unhelpful.)

>  I can envisage a situation where BOTs caught at the front end MTAs could be sent.

No.

If it's caught at the MTA, then the MTA operator will decide where to send the reports.

>  MTAs doing it would be instant death on a forged target, even if the MTAs hard rate limited (think backscatter bomb).  It could also be instant death on a non-forged target, but they're more likely to be able to handle it.

No, that cannot happen.

> 
> Then there's Joe Jobs.  Not necessarily so much with source IPs, but with, say, web site payloads getting falsely accused.

No. At worst that's exactly the same as the status quo.

In the approach I'm suggesting, the only time a report will be sent to the email address embedded in the headers of the original email by the sender is when


  1. Neither the mailbox provider, nor any forwarder (e.g. acm.org) choose to be aware of the protocol

  and

  2. The mail is delivered to the end recipients inbox

  and

  3. The recipients MUA is aware of the protocol

  and

  4. The end recipient manually marks the message as spam


If any of those four requirements is not fulfilled, then no report will be sent to any email address embedded in the original message by the sender. If you're going to argue about how this will cause problems, you need to do so in that context.


Cheers,
  Steve