Re: [Asrg] Adding a spam button to MUAs

Douglas Otis <> Fri, 29 January 2010 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DFEE3A677C for <>; Fri, 29 Jan 2010 14:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.443
X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 YJnRq6baJMir for <>; Fri, 29 Jan 2010 14:58:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B297A3A63EC for <>; Fri, 29 Jan 2010 14:58:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6C400A945FF for <>; Fri, 29 Jan 2010 22:58:20 +0000 (UTC)
Message-ID: <>
Date: Fri, 29 Jan 2010 14:58:19 -0800
From: Douglas Otis <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 29 Jan 2010 22:58:01 -0000

On 1/29/10 12:37 PM, Michael Thomas wrote:
> no, no, no, you misunderstand me. I'm not saying that prefiltering is 
> bad. far from it.
> this started out with the claim that end users with their TiS buttons 
> are between useless
> and dangerous. Users may not get all bad things (duh), but they also 
> know a heck of a
> lot more about what they don't want than some system-wide classifier 
> that is BY DESIGN
> allergic to false positives.
> And I'll take issue with "only absolute classification helps solve 
> Rich's problem." In fact,
> users on a day 0 exploit are your only line of defence so you better 
> damn well hope that
> some percentage of them push the panic button, and you'd be foolish to 
> not
> build systems that take those early warnings into account.
> The point i'm making is that the user MUST be a part of the larger 
> problem of managing
> their own firehose. The absolutist 
> "spam/ham"-must-be-part-of-priesthood is but one way
> to achieve a level of filtering with relatively few false positives, 
> but it is not the whole
> picture.  The whole picture is "don't show me what I don't want to see".


It really depends upon how feedback is applied.  When applied globally 
and not for the individual offering the feedback, then this _will_ cause 
false positive detections.  You are right, this type of information does 
provide early indications that content filtering is failing to detect 
some new spam variant, but then this requires human intervention to repair.

What I don't understand is your desire to muddle with spam definitions 
calling the feedback "This is Spam" and not "This is Junk".  Calling it 
junk accurately describes how it is used, and what it ultimately means.  
You don't need to be part of priesthood to understand what might cause 
false positive blocking of otherwise legitimate messages.

Recently,  our group made this mistake of mis-applying this type of 
feedback, where the confusion appeared due to the sloppy labeling of 
feedback as "spam" when it really meant, "not wanted".  Not wanted is 
usually the output of any content filter as well,  the result of the 
filter's training.