Re: [Asrg] Adding a spam button to MUAs

Nathaniel Borenstein <nsb@guppylake.com> Tue, 22 December 2009 19:54 UTC

Return-Path: <nsb@guppylake.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 D16943A6906 for <asrg@core3.amsl.com>; Tue, 22 Dec 2009 11:54:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.871
X-Spam-Level: ***
X-Spam-Status: No, score=3.871 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FB_CIALIS_LEO3=3.899, HTML_MESSAGE=0.001, 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 Gf86Oe4iaPtl for <asrg@core3.amsl.com>; Tue, 22 Dec 2009 11:54:30 -0800 (PST)
Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id F3DFB3A69FA for <asrg@irtf.org>; Tue, 22 Dec 2009 11:54:29 -0800 (PST)
Received: from 173-114-216-132.pools.spcsdns.net ([173.114.216.132]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from <nsb@guppylake.com>) id 1NNAoe-0000Sf-6D for asrg@irtf.org; Tue, 22 Dec 2009 14:54:45 -0500
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> <20091217200605.8E99E2421D@panix5.panix.com> <4B2B0E4B.3050509@dcrocker.net> <4B2E1E76.9000400@mines-paristech.fr> <A8792A43052B049E5A4851E5@lewes.staff.uscs.susx.ac.uk> <20091221154631.2752024221@panix5.panix.com> <2AC70D28E4DDDF2D65492536@lewes.staff.uscs.susx.ac.uk> <4B3105B5.6060701@mtcc.com>
From: Nathaniel Borenstein <nsb@guppylake.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-29--263394148"
In-Reply-To: <4B3105B5.6060701@mtcc.com>
Message-Id: <BE1653E1-735B-47A7-AE96-847A1786BE2B@guppylake.com>
Date: Tue, 22 Dec 2009 14:54:07 -0500
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Mime-Version: 1.0 (Apple Message framework v1077)
X-Mailer: Apple Mail (2.1077)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server1.netnutz.com
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - guppylake.com
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 19:54:30 -0000

On Dec 22, 2009, at 12:45 PM, Michael Thomas wrote:
> 
> And it's not like this sort of thing is anything new anyway: lots of vendors have "report as
> spam" widgets that get bolted onto the side of your favorite MUA. A little standardization
> would be nice though as it would decouple that UI hassle from the actual job of filtering.

Absolutely -- the report-spam UI will almost certainly be better if it's integrated with the MUA and agnostic regarding the spam engine receiving the report.  The only major open question I'm hearing is how much information that report should contain.  Clearly it should be no more than the number of bits that the user himself can be relied on to provide, where our differing opinions might be resolved via user studies.

It might also be worth considering offering 1 button to most users, but 2 buttons to users who understand the distinction well enough to change a default in their MUA in order to get 2 buttons instead of 1.  I conjecture that the users who would take that action would have a much lower error rate than the average user.   In that scenario, most users would send back a single bit "unwanted" message, but sophisticated users could send back two (or even more?) types of "unwanted" message.  That might be the cleanest data we could hope to get. -- Nathaniel