Re: [Asrg] Adding a spam button to MUAs

Seth <> Wed, 16 December 2009 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A53A3A6A19 for <>; Wed, 16 Dec 2009 10:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V30Mk8K4T3yC for <>; Wed, 16 Dec 2009 10:59:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5852D3A69C6 for <>; Wed, 16 Dec 2009 10:59:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4BB7E38E48 for <>; Wed, 16 Dec 2009 13:59:04 -0500 (EST)
Received: by (Postfix, from userid 756) id 3B9032421D; Wed, 16 Dec 2009 13:59:04 -0500 (EST)
From: Seth <>
In-reply-to: <> (message from Rich Kulawiec on Wed, 16 Dec 2009 07:07:42 -0500)
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan> <> <> <>
Message-Id: <>
Date: Wed, 16 Dec 2009 13:59:04 -0500 (EST)
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: Wed, 16 Dec 2009 18:59:19 -0000

Rich Kulawiec <> wrote:
> On Tue, Dec 15, 2009 at 05:50:24PM -0800, Steve Atkins wrote:
>> > I think allowing end users access to such a button is a terrible idea.
>> Data from actual reality contradicts your (otherwise plausible) reasoning.
> Not my data.  I have a rather large collection of incidents involving
> message recipients who have marked as spam:

What fraction of the total spam complaints you received were bogus
like those?

> Users as a group are far too clueless and careless to be permitted the
> privilege of access to such a feature.

That depends on what the feature _does_.  A lot of inaccurate
measurements can be used to make a few very accurate measurements.

> There's the zombie problem.  There is no way for anyone or anything
> external to an end-user's system to know whether the button click
> (or equivalent event) was generated by a user or by software working
> at the behest of the new owner of the user's former system.  Given
> that the zombie problem is epidemic and presently unstoppable,
> widescale deployment of any such mechanism will lead to its use by
> zombie-resident malware as soon as it's advantageous for abusers to
> do so. Thus, anyone proposing such a "report as spam" mechanism on a
> large scale must also include in their proposal a workable plan for
> solving the zombie problem.

How would it be advantageous for a zombie to report as spam?  Report
as non-spam, sure, to game the filters.  But with the data being noisy
to begin with, zombies adding noise don't have much effect; they might
require tuning of the filters.