Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <> Thu, 28 January 2010 05:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71CD13A68A7 for <>; Wed, 27 Jan 2010 21:42:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.836
X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fCmrFc3qm3F0 for <>; Wed, 27 Jan 2010 21:42:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 76D093A682B for <>; Wed, 27 Jan 2010 21:42:16 -0800 (PST)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by with ESMTPSA; Thu, 28 Jan 2010 06:42:31 +0100 id 00000000005DC02F.000000004B6123C7.0000038A
Message-ID: <>
Date: Thu, 28 Jan 2010 06:42:31 +0100
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; 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: Thu, 28 Jan 2010 05:42:17 -0000

On 28/Jan/10 03:46, Douglas Otis wrote:
> 2) Not all unwanted email falls into a definition of spam.
> Unfortunately, when provided a limited set of options, pressing a "This
> is Spam" button likely communicates a message as unwanted or is
> considered junk, even when from a mailing-list previously opted in, or
> perhaps an auto-response in language the end-user is unable to read.
> After all, not all recipients share a common native language.

Even worse, users will learn what the button means by the effect (they 
think) they obtain by hitting it, which may vary.

I'd consider bringing up a confirmation dialog when disambiguation is 

> End-users can be a poor judge as to what is spam. Abuse desks receiving
> complaints of unwanted email need to ascertain whether there is evidence
> of spam, such as content clearly in the commercial interest of the
> sender, and not the recipient, etc.

One key point is to establish which complaints require human 
inspection and why. This can be done better deploying collaborative 
interchange with trusted senders.