Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <> Thu, 31 December 2009 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 326AC3A6A64 for <>; Thu, 31 Dec 2009 10:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.143
X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=-3.079, BAYES_50=0.001, FB_CIALIS_LEO3=3.899, 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 WdFFSPveGREP for <>; Thu, 31 Dec 2009 10:28:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2D5A63A65A6 for <>; Thu, 31 Dec 2009 10:28:17 -0800 (PST)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by with esmtp; Thu, 31 Dec 2009 19:27:56 +0100 id 00000000005DC037.000000004B3CED2C.00000B7A
Message-ID: <>
Date: Thu, 31 Dec 2009 19:27:56 +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
To: Anti-Spam Research Group - IRTF <>
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
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, 31 Dec 2009 18:28:19 -0000

Michael Thomas wrote:
> Nathaniel Borenstein wrote:
>> Absolutely -- the report-spam UI will almost certainly be better if 
>> it's integrated with the MUA and agnostic regarding the spam engine 
>> receiving the report.  The only major open question I'm hearing is how 
>> much information that report should contain.  Clearly it should be no 
>> more than the number of bits that the user himself can be relied on to 
>> provide, where our differing opinions might be resolved via user studies.

Different mailbox providers may process reports in widely different 
ways. While UI's behavior is agnostic, its configuration may refer to 
specific functionalities that the underlying spam engine may or may 
not support.

>> It might also be worth considering offering 1 button to most users, 
>> but 2 buttons to users who understand the distinction well enough to 
>> change a default in their MUA in order to get 2 buttons instead of 1. 
>>  I conjecture that the users who would take that action would have a 
>> much lower error rate than the average user.   In that scenario, most 
>> users would send back a single bit "unwanted" message, but 
>> sophisticated users could send back two (or even more?) types of 
>> "unwanted" message.  That might be the cleanest data we could hope to 
>> get.

Sophisticated users may choose a mailbox provider according to what 
functionalities it offers. Conversely, ISPs may offer different 
functionalities in order to attract different kinds of users. A good 
MUA should support them all.

> I think the problem is that if you open it up to more than one bit, it 
> begs the question of what the
> actual number of bits such a button is. I'd say that it's probably got a 
> lot of bits -- far more than is 
> likely that any user could be bothered with.

Assuming that the MUA will use ARF, the number of bits that can be 
stuffed in there is defined by that format and its extensions.

> Want/don't want is nice in its simplicity, and I suspect it's about as 
> much as you can expect from users. [...]
> I think that if we stopped with this absolutist campaign of  "spam/ham" 
> (most of us are not on some 
> paladin's quest  against the evils of spam, after all) and focused more 
> on the context sensitive job of 
> prioritizing mail, we'd all be a lot better off.

"Ham/spam" is not any better than "wanted/not-wanted", as far as 
coherence is concerned. "Legitimate/abusive, w.r.t. applicable privacy 
laws" would perhaps be clearer.

Rather than campaigns, it is a question of functionalities. Servers 
who support mail priority should be able to use reports for that sake. 
Ditto for block or unsubscribe. MGRSs might provide for one additional 
functionality: ban the sender from sending for an amount of time 
proportional to the number of complaints. I'd consider the latter an 
exercise of direct judicial process.