Re: [Asrg] Adding a spam button to MUAs

"Chris Lewis" <> Sat, 30 January 2010 04:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D86E93A690D for <>; Fri, 29 Jan 2010 20:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.343
X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zeI+jnqOweSs for <>; Fri, 29 Jan 2010 20:56:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BB2E53A68FF for <>; Fri, 29 Jan 2010 20:56:20 -0800 (PST)
Received: from ( []) by (Switch-2.2.0/Switch-2.2.0) with ESMTP id o0U4uf117689 for <>; Sat, 30 Jan 2010 04:56:41 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 23:56:40 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 29 Jan 2010 23:56:40 -0500
Message-ID: <>
Date: Fri, 29 Jan 2010 23:56:40 -0500
From: "Chris Lewis" <>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Lightning/0.9 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Jan 2010 04:56:40.0987 (UTC) FILETIME=[9C9FCEB0:01CAA168]
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: Sat, 30 Jan 2010 04:56:22 -0000

Bart Schaefer wrote:

> These two foci are in conflict.  For Rich, it's obvious that end users
> have limited expertise in distinguishing undesirable traffic; and to
> allow the users to express their opinion, he must first allow that
> traffic to pass, which is unacceptably dangerous, possibly disruptive,
> and violates the "as early as possible" constraint.  Only an absolute
> classification helps to solve Rich's problem.

Your description actually means that nothing can be blocked without a 
user first saying it should be blocked.  IOW, the foci you've described 
can't block, ever, because the user hasn't told you yet it's bad, and by 
the act of seeing it, the choice to block or not is moot.

That's obviously silly.

Remember: TiS buttons are intended to catch those things that your 
filters didn't _already_ capture.  They're to refine your filters for 
future repeats of the same thing (however "same" is defined).  _Not_ 
_be_ the filters.

If the filters can tell something is bad, you block it, no matter how 
you've determined it to be bad.  No TiS hits necessary.

TiS is an _adjunct_ to your filtering strategy.  Not the whole thing.

> Rich may be overly dismissive of Mike's problem, but to declare concerns
> about maintenance and security to be anachronisms not part of the "actual
> job" is to repeat the mistakes of the past.

Mike is not dismissing it.  I certainly ain't, because I have to 
maintain and secure the darn thing.  TiS buttons certainly don't 
compromise our maintenance and security.