Re: [Asrg] Adding a spam button to MUAs

Michael Thomas <mike@mtcc.com> Fri, 29 January 2010 20:37 UTC

Return-Path: <mike@mtcc.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 7317C3A67DA for <asrg@core3.amsl.com>; Fri, 29 Jan 2010 12:37:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level:
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 QGVccOxJW0a8 for <asrg@core3.amsl.com>; Fri, 29 Jan 2010 12:37:36 -0800 (PST)
Received: from mtcc.com (mtcc.com [64.142.29.208]) by core3.amsl.com (Postfix) with ESMTP id 5534A3A659A for <asrg@irtf.org>; Fri, 29 Jan 2010 12:37:36 -0800 (PST)
Received: from piolinux.mtcc.com (65-172-208-49.dsl.volcano.net [65.172.208.49]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id o0TKbuR9005323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <asrg@irtf.org>; Fri, 29 Jan 2010 12:37:58 -0800
Message-ID: <4B634723.1050604@mtcc.com>
Date: Fri, 29 Jan 2010 12:37:55 -0800
From: Michael Thomas <mike@mtcc.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
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> <4B63199A.4040200@mtcc.com> <100129100819.ZM8697@torch.brasslantern.com>
In-Reply-To: <100129100819.ZM8697@torch.brasslantern.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2741; t=1264797479; x=1265661479; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[Asrg]=20Adding=20a=20spam=20button=20t o=20MUAs |Sender:=20 |To:=20Anti-Spam=20Research=20Group=20-=20IRTF=20<asrg@irtf .org> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Pz0dhtXQ8fZuBpt6CBkF8jD6DZJl1Ngp7H1P4XRv9Vg=; b=osanYNcQ1KUIqxrBWB11LWwpdxH+wy2gXXJms/Wk0aNlTCb+BrgZ/ot4S2 XoehZAgpSaG+Mt93E59CUkVyqijh57M5VgjbEJnIr66bHqN+fS+JDHB1G3Ek E6yc+GfVkSXTSc432j6fCqwLD93FURl26e6LZjC6bA/sinVBGAHD4=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.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: Fri, 29 Jan 2010 20:37:37 -0000

Bart Schaefer wrote:
> On Jan 29,  9:23am, Michael Thomas wrote:
> }
> } The question should always be: "does user X want this mail?" rather
> } than "this mail is spam/ham in absolute terms". The sooner we get
> } beyond the paleospamogist priesthood, the sooner we get on with the
> } actual job of building products for its users rather than the various
> } other vested interests.
>
> I think the trouble here is that there are actually two different
> problems being conflated.
>
> Mike is focused on the problem of making the users happy, which means
> both eliminating content they don't want to be bothered with, and *not*
> eliminating content they find desirable.
>
> Rich is focused on the problem of network maintenance and security,
> which means eliminating unwanted/malicious traffic as early as possible 
> and with minimal disruption to the important/innocuous traffic.
>
> 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.
>   

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".
> 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.
> _______________________________________________
> Asrg mailing list
> Asrg@irtf.org
> http://www.irtf.org/mailman/listinfo/asrg
>