Re: [Asrg] Adding a spam button to MUAs

Rich Kulawiec <> Wed, 16 December 2009 12:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78B0D3A680A for <>; Wed, 16 Dec 2009 04:47:19 -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=[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 uvf8j3Fm8YS2 for <>; Wed, 16 Dec 2009 04:47:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7E0C93A67EA for <>; Wed, 16 Dec 2009 04:47:18 -0800 (PST)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id nBGCl3vu002969 for <>; Wed, 16 Dec 2009 07:47:04 -0500 (EST)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id nBGCmC4K002759 for <>; Wed, 16 Dec 2009 07:48:16 -0500 (EST)
Received: from (localhost []) by (8.14.3/8.14.3/Debian-4) with ESMTP id nBGCf7PY006463 for <>; Wed, 16 Dec 2009 07:41:08 -0500
Received: (from rsk@localhost) by (8.14.3/8.14.3/Submit) id nBGC7gmN029362 for; Wed, 16 Dec 2009 07:07:42 -0500
Date: Wed, 16 Dec 2009 07:07:42 -0500
From: Rich Kulawiec <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.18 (2008-05-17)
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: Wed, 16 Dec 2009 12:47:19 -0000

On Tue, Dec 15, 2009 at 05:50:24PM -0800, Steve Atkins wrote:
> > I think allowing end users access to such a button is a terrible idea.
> Data from actual reality contradicts your (otherwise plausible) reasoning.

Not my data.  I have a rather large collection of incidents involving
message recipients who have marked as spam:

	- personal messages
	- professional messages
	- system-generated messages
	- ordinary mailing list traffic
	- monthly mailing list you-are-subscribed reminders
	- mailing list subscription confirmations
	- etc.

In the case of the first several, this includes messages requested
by those same users or replies to their own.  In the case of the last
several, treating said false spam reports as "unsubscribes" has led
to indignant protests that they did not wish to be unsubscribed.
In the case of all of them, other-channel personal contact has almost
without exception led to denials that the button was used, followed by
admissions of error when proof demonstrating same was produced.

Users as a group are far too clueless and careless to be permitted the
privilege of access to such a feature.  If they weren't so clueless and
careless, then phishing would be an insignificant problem and outbound
mail logs would not show a constant stream of attempted replies and
unsubscribes to blindingly obvious spam.

But beyond that:

There's the zombie problem.  There is no way for anyone or anything
external to an end-user's system to know whether the button click (or
equivalent event) was generated by a user or by software working at
the behest of the new owner of the user's former system.  Given that the
zombie problem is epidemic and presently unstoppable, widescale deployment
of any such mechanism will lead to its use by zombie-resident malware as
soon as it's advantageous for abusers to do so. Thus, anyone proposing
such a "report as spam" mechanism on a large scale must also include in
their proposal a workable plan for solving the zombie problem.