Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <vesely@tana.it> Fri, 18 December 2009 08:13 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 2FDC53A6813 for <asrg@core3.amsl.com>; Fri, 18 Dec 2009 00:13:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.315
X-Spam-Level:
X-Spam-Status: No, score=-4.315 tagged_above=-999 required=5 tests=[AWL=0.248, 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 y7s0wdlG24Jz for <asrg@core3.amsl.com>; Fri, 18 Dec 2009 00:13:45 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id E6E163A684E for <asrg@irtf.org>; Fri, 18 Dec 2009 00:13:41 -0800 (PST)
Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 18 Dec 2009 09:13:25 +0100 id 00000000005DC031.000000004B2B39A5.000059A1
Message-ID: <4B2B3A19.8010008@tana.it>
Date: Fri, 18 Dec 2009 09:15:21 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan> <20091216014800.GA29103@gsp.org> <DBF77720-200E-4846-949F-924388F9CC15@blighty.com> <20091216120742.GA28622@gsp.org> <20091216185904.3B9032421D@panix5.panix.com> <4B296458.5070603@mail-abuse.org> <16C1C8A4-D223-435B-93BC-A9D44F5965A1@guppylake.com> <B14EC7430355853625D0D4EA@lewes.staff.uscs.susx.ac.uk> <BBF2AC03-3C88-4557-9346-343347C196A9@guppylake.com> <240DB04672256506ED548857@lewes.staff.uscs.susx.ac.uk> <4B2A7E8D.8060104@nd.edu> <20091217200605.8E99E2421D@panix5.panix.com> <4B2B0E4B.3050509@dcrocker.net>
In-Reply-To: <4B2B0E4B.3050509@dcrocker.net>
Content-Type: text/plain; charset=ISO-8859-1; 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, 18 Dec 2009 08:13:54 -0000

Dave CROCKER wrote:
> On 12/17/2009 12:06 PM, Seth wrote:
>> We don't know that it _will_ be the worst case.  To the extent there
>> are _some_ users who can tell the difference (and the admin can tell
>> the difference between them and other users), having two buttons gives
>> better information.
> 
> unless there are _some_ users who are more confused by the choice.  UI 
> complexity is not reduced by having more buttons; reducing complexity 
> leads to better UI, particularly for the mass market.

For homogeneity of behavior, I'd note that the buttons resulting in 
sending a message out --Reply, Forward-- open a dialog that shows 
the recipient(s) and the content being sent.

For TiS buttons, older discussions seem to indicate that we don't 
want users to type text. (Therefore, well aimed complaints intended 
for manual evaluation would still go via the Forward button.) 
However, the dialog could sport checkboxes or radiobuttons set up 
according to, say, presence of List-Unsubscribe or 
Authentication-Results headers. Users may adjust these flags before 
hitting Send.

If we want to feed Bayesian filters, we need a spam/ham button.

If messages classified as junk by client filters are automatically 
reported as spam, this circumstance should be flagged on the 
outgoing abuse reports.

> as nathaniel notes, these types of design choices for UI design require 
> testings.

Yes, and I expect users behavior under traditional MUAs will be 
somewhat different from that of web interfaces users. I'd also 
expect behavior to vary widely among different mail domains.