Re: [Asrg] Adding a spam button to MUAs

"Chris Lewis" <clewis@nortel.com> Sat, 30 January 2010 04:42 UTC

Return-Path: <CLEWIS@nortel.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 356D23A6898 for <asrg@core3.amsl.com>; Fri, 29 Jan 2010 20:42:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.293
X-Spam-Level:
X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Lp5sDNQhZqz8 for <asrg@core3.amsl.com>; Fri, 29 Jan 2010 20:42:22 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 270793A68D1 for <asrg@irtf.org>; Fri, 29 Jan 2010 20:42:21 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o0U4gg117287 for <asrg@irtf.org>; Sat, 30 Jan 2010 04:42:42 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 23:42:42 -0500
Received: from [47.130.64.135] (47.130.64.135) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 29 Jan 2010 23:42:41 -0500
Message-ID: <4B63B8C1.7000404@nortel.com>
Date: Fri, 29 Jan 2010 23:42:41 -0500
From: "Chris Lewis" <clewis@nortel.com>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20100128173112.85215.qmail@simone.iecc.com> <4B61CC2F.404@mtcc.com> <20100129134451.GA27203@gsp.org>
In-Reply-To: <20100129134451.GA27203@gsp.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Jan 2010 04:42:42.0419 (UTC) FILETIME=[A8CC7C30:01CAA166]
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: Sat, 30 Jan 2010 04:42:24 -0000

Rich Kulawiec wrote:

> I don't think this is elitist, I think it's a matter of recognizing that
> the spam/not-spam classification process requires expertise *vastly* in
> excess of that possessed by almost all users.  This is not their "fault"
> per se because it's not a fault: it's simply a lack of area-specific
> experience and knowledge.

You seem to be seeing it only as "a single ordinary user making 
site-wide decisions on what to block" versus "totally ignoring what the 
users say" choice.

If that binary choice was the only choice, I'd agree with you.  I have 
enough horror stories of goofs in that regard.  Hell, I have enough 
horror stories when the alleged expert (me) screws up good.

But that is _not_ the choice.  Acting as if it is is at least mistaken. 
  TiS buttons aren't implemented that way.

_Nobody_ is talking about individual ordinary users making site-wide 
decisions of what to block.  That requires very high levels of expertise 
as you say.  But there is absolutely nothing whatsoever wrong with 
taking note of what those individual users are saying, and using it in a 
statistical fashion to guide your filtering.  That is how TiS buttons 
are used in infrastructures large enough to bother with them.  It is, 
after all, how Spamcop was originally implemented, and it's still part 
of their decisioning process albeit less than it used to be.

There are non-user-driven DNSBLs less useful than Spamcop ;-)

If we were to specify/standardize/or even (gasp) implement a common TiS 
strategy/implementation that actually drives filters, the crucial part 
is coming up with a "filter decisioning" strategy that the admins can 
tune, and has reasonable defaults.