Re: [Asrg] Adding a spam button to MUAs

Daniel Feenberg <feenberg@nber.org> Tue, 22 December 2009 14:44 UTC

Return-Path: <feenberg@nber.org>
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 949B83A6881 for <asrg@core3.amsl.com>; Tue, 22 Dec 2009 06:44:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.607
X-Spam-Level:
X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[AWL=0.836, 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 4WoYtMg87hII for <asrg@core3.amsl.com>; Tue, 22 Dec 2009 06:44:06 -0800 (PST)
Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id 42BB13A67B5 for <asrg@irtf.org>; Tue, 22 Dec 2009 06:44:05 -0800 (PST)
Received: from nber5.nber.org (nber5.nber.org [66.251.72.75]) by mail2.nber.org (8.14.3/8.13.8) with ESMTP id nBMEhka3098727 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <asrg@irtf.org>; Tue, 22 Dec 2009 09:43:47 -0500 (EST) (envelope-from feenberg@nber.org)
Received: from nber5.nber.org (localhost [127.0.0.1]) by nber5.nber.org (8.13.8+Sun/8.13.8) with ESMTP id nBMEWxbM000944; Tue, 22 Dec 2009 09:32:59 -0500 (EST)
Received: from localhost (feenberg@localhost) by nber5.nber.org (8.13.8+Sun/8.13.8/Submit) with ESMTP id nBMEWxkx000941; Tue, 22 Dec 2009 09:32:59 -0500 (EST)
X-Authentication-Warning: nber5.nber.org: feenberg owned process doing -bs
Date: Tue, 22 Dec 2009 09:32:59 -0500 (EST)
From: Daniel Feenberg <feenberg@nber.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <E12D471E9BA7C62AC1CE7453@lewes.staff.uscs.susx.ac.uk>
Message-ID: <Pine.GSO.4.64.0912220923370.27655@nber5.nber.org>
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan> <20091216014800.GA29103@gsp.org> <DBF77720-200E-4846-949F-924388F9CC15@blighty.com> <20091216120742.GA28622@gsp.org> <20091216185904.3B9032421D@panix5.panix.com> <4B296458.5070603@mail-abuse.org> <16C1C8A4-D223-435B-93BC-A9D44F5965A1@guppylake.com> <B14EC7430355853625D0D4EA@lewes.staff.uscs.susx.ac.uk> <BBF2AC03-3C88-4557-9346-343347C196A9@guppylake.com> <240DB04672256506ED548857@lewes.staff.uscs.susx.ac.uk> <4B2A7E8D.8060104@nd.edu> <AF09C4BE1E9DB501F0D2CDF3@paine.local> <940DF2A7-C912-49C1-B967-E82CA69649D3@guppylake.com> <4B2FBD46.1010809@leisi.net> <E12D471E9BA7C62AC1CE7453@lewes.staff.uscs.susx.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20091221 #3397201, check: 20091222 clean
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: Tue, 22 Dec 2009 14:44:07 -0000

On Tue, 22 Dec 2009, Ian Eiloart wrote:

>
>
> --On 21 December 2009 19:24:06 +0100 Matthias Leisi <matthias@leisi.net> 
> wrote:
>
>> 
>> Am 21.12.09 18:46, schrieb Nathaniel Borenstein:
>> 
>>> distinction, it's whether the users can.  If the users can't use the
>>> client's two buttons with sufficiently low error rates, then the
>>> resulting data can't possibly be useful to the admins.  In other
>> 
>> When I was responsible for spamfilter operation at a former job, error
>> rates of "human spamfilters" were considerably higher than FP rates of
>> any possible solution. This is not scientific evidence, but it
>> illustrates it nicely:
>
> I nice story. It says that we must not block mail on a single report, 
> especially a report from a different user. That's fair enough, but it's not 
> what anyone is suggesting.
>
> The current question is how can we make it easier for users to report spam to 
> administrators. The question of what administrators do with the reports is 
> secondary - though it might inform the kind of information that they want to 
> gather.
>
>

Whether you want one or two buttons depends upon whether you have one or 
two actions to take. If you have only individual spam filters, then you 
only need one button, call it the "unwanted - unsubscribe" button which 
would attempt to unsubscribe where suitable headers were present, and 
would block otherwise. If you have both individual and global filters, 
then you need both "unwanted - unsubscribe" and "spam" buttons. And you 
probably want to inspect the "spam" items before adding them to any global 
filter.

If I review my own decisions later, I find that about 1% of the 
time I call something I want spam, but I am much more likely to fail to 
call spam as spam. In any case the error percentage must be calculated as 
a percentage of mail, not a percentage of reports to be usefull.

As to the accuracy of user decisions, if you give users only one button, 
they are likely to be less accurate than if they have two buttons. since
they will have no opportunity to select the correct button, they will 
likely select the wrong one rather than do nothing at all.

Daniel Feenberg