Re: [Asrg] Adding a spam button to MUAs

Ian Eiloart <> Thu, 17 December 2009 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1DF93A681E for <>; Thu, 17 Dec 2009 08:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.074
X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FUmHDMdFklU5 for <>; Thu, 17 Dec 2009 08:26:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CD7EA3A63EB for <>; Thu, 17 Dec 2009 08:26:52 -0800 (PST)
Received: from ([]:54921) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KUT1QC-000F1J-1D for; Thu, 17 Dec 2009 16:27:48 +0000
Date: Thu, 17 Dec 2009 16:26:37 +0000
From: Ian Eiloart <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <>
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan> <> <> <>
Originator-Info: login-token=Mulberry:01QLZLa6kXudCBI5/NrNyzK77epi5sxaPctSE=;
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
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: Thu, 17 Dec 2009 16:26:53 -0000

--On 16 December 2009 12:08:43 -0500 Paul Russell <> wrote:

> On 12/15/2009 20:50, Steve Atkins wrote:
>> On Dec 15, 2009, at 5:48 PM, Rich Kulawiec wrote:
>>> I think allowing end users access to such a button is a terrible idea.
>>> This is the same population that routinely replies to spam, falls for
>>> phishes, and fails to correctly execute rudimentary tasks like
>>> unsubscribing from a mailing list or trimming quoted material from
>>> replies.  It would be simpler and about as accurate to simply check a
>>> random number generator's output for a "spam?/not-spam?" opinion.
>> Data from actual reality contradicts your (otherwise plausible)
>> reasoning.
> Our "actual reality" includes an AOL feedback loop stream that consists
> primarily of:
> * spam complaints about personal messages from family members or friends;
> * spam complaints about replies to messages initially sent by the user who
>   subsequently reported the reply as spam;
> * spam complaints about messages posted to COI lists to which the user had
>   previously and explicitly subscribed.
> None of these messages should have been reported as spam, but they were,
> and they outnumber legitimate complaints by a wide margin.

We get similar types of response, but the most common reports are about our 
Mailman mailing lists, and other bulk messages that we send. As far as I'm 
concerned they're legitimate complaints, but the volume would be much lower 
if (a) an "unsubscribe instead of complain" feature were implemented for 
lists, and (b) our alumni office would take more care with their lists 
(they're working on it).

I think the reason for a lot of these complaints is the completely hopeless 
AOL webmail interface for the feature. The "junk" button is right next to 
the delete button. Since the last time I looked (April '09), they've added 
about 5 pixels of separation between the two, but that separation hasn't 
always been there. I'd love to know what the mis-click rate is, and how it 
changed with the addition of some space. Subjectively, I've noticed a much 
lower rate of spam reporting from AOL, but can't say whether that coincided 
with the change, since I don't know when the change happened.

Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see