Re: [Asrg] Adding a spam button to MUAs

Bart Schaefer <schaefer@brasslantern.com> Fri, 29 January 2010 18:08 UTC

Return-Path: <schaefer@closedmail.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 5E01E3A6916 for <asrg@core3.amsl.com>; Fri, 29 Jan 2010 10:08:23 -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 P1FBsvP6m-WT for <asrg@core3.amsl.com>; Fri, 29 Jan 2010 10:08:22 -0800 (PST)
Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by core3.amsl.com (Postfix) with ESMTP id 9C5643A68B4 for <asrg@irtf.org>; Fri, 29 Jan 2010 10:08:22 -0800 (PST)
Received: from torch.brasslantern.com ([unknown] [173.67.92.79]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KX000KNMT1WPVVG@vms173011.mailsrvcs.net> for asrg@irtf.org; Fri, 29 Jan 2010 12:08:21 -0600 (CST)
Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id o0TI8JVq008699 for <asrg@irtf.org>; Fri, 29 Jan 2010 10:08:20 -0800
Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id o0TI8JuU008698 for asrg@irtf.org; Fri, 29 Jan 2010 10:08:19 -0800
From: Bart Schaefer <schaefer@brasslantern.com>
Message-id: <100129100819.ZM8697@torch.brasslantern.com>
Date: Fri, 29 Jan 2010 10:08:19 -0800
In-reply-to: <4B63199A.4040200@mtcc.com>
Comments: In reply to Michael Thomas <mike@mtcc.com> "Re: [Asrg] Adding a spam button to MUAs" (Jan 29, 9:23am)
References: <20100128173112.85215.qmail@simone.iecc.com> <4B61CC2F.404@mtcc.com> <20100129134451.GA27203@gsp.org> <4B63199A.4040200@mtcc.com>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
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 18:08:23 -0000

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.

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.