Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <vesely@tana.it> Fri, 29 January 2010 10:05 UTC

Return-Path: <vesely@tana.it>
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 E90623A693E for <asrg@core3.amsl.com>; Fri, 29 Jan 2010 02:05:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.789
X-Spam-Level:
X-Spam-Status: No, score=-4.789 tagged_above=-999 required=5 tests=[AWL=-0.226, 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvcMsMnY4w4H for <asrg@core3.amsl.com>; Fri, 29 Jan 2010 02:05:24 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id D39C43A6876 for <asrg@irtf.org>; Fri, 29 Jan 2010 02:05:23 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 29 Jan 2010 11:05:41 +0100 id 00000000005DC03D.000000004B62B2F5.00000AE4
Message-ID: <4B62B2F5.50007@tana.it>
Date: Fri, 29 Jan 2010 11:05:41 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: asrg@irtf.org
References: <20100128173112.85215.qmail@simone.iecc.com> <4B61CC2F.404@mtcc.com> <4B61DBF8.60006@mail-abuse.org> <387E2502-61E5-4811-B4EB-36AE47ADC648@blighty.com>
In-Reply-To: <387E2502-61E5-4811-B4EB-36AE47ADC648@blighty.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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 10:05:25 -0000

On 28/Jan/10 20:03, Steve Atkins wrote:
>>>  On 01/28/2010 09:31 AM, John Levine wrote:
>>>>>  Even worse, users will learn what the button means by the effect (they
>>>>>  think) they obtain by hitting it, which may vary.
>>>>  Web mail has had spam buttons for years, and the users seem to have
>>>>  figured out how to use them.  Can you explain exactly how the issues
>>>>  with a spam button in a MUA would be different?

Because some ISPs' sizes result in vanishing likelihoods that Alice 
and Bob share the same server (see the "ideal" FP example). Nor we can 
expect smaller ISPs to implement FBLs on their own initiative...

> Most of the people I see arguing that the "this is spam" button isn't
> a good user interface for users to provide their thoughts are spammers
> or grey area bulk mailers.
>
> There's a smattering of operationally inexperienced anti-spam nuts,
> and dilettantes who have nothing more productive to do than argue about the
> wording of AOLs user interface and the colour the AOL bikeshed should be
> painted, but it's mostly spammers and dirty bulk mailers.

These statements are highly enlightening! They implicitly contain an 
explanation of why we cannot define the term /spam/, and what kind of 
hypocritical equilibrium results from coloring bulk mailers with 
various shades of gray. Since marketers want to send ads and users 
don't want to receive them, MTA operators can pretend there is no 
conflict and provide a direct-to-junk channel. Is everybody happy with 
this [non-]solution?

IMHO it doesn't work very well: First, because ambiguity undermines 
reliability. Second, because users have no direct control.