Re: [Asrg] Summary of junk button discussion

"Chris Lewis" <clewis@nortel.com> Thu, 25 February 2010 06:20 UTC

Return-Path: <CLEWIS@nortel.com>
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 D158D3A864A for <asrg@core3.amsl.com>; Wed, 24 Feb 2010 22:20:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.459
X-Spam-Level:
X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, 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 A-55xYqav3E1 for <asrg@core3.amsl.com>; Wed, 24 Feb 2010 22:20:35 -0800 (PST)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C746B3A8649 for <asrg@irtf.org>; Wed, 24 Feb 2010 22:20:34 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1P6MdG25562 for <asrg@irtf.org>; Thu, 25 Feb 2010 06:22:39 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Feb 2010 01:22:39 -0500
Received: from [47.130.64.199] (47.130.64.199) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 25 Feb 2010 01:22:38 -0500
Message-ID: <4B86172D.2080702@nortel.com>
Date: Thu, 25 Feb 2010 01:22:37 -0500
From: "Chris Lewis" <clewis@nortel.com>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: <asrg@irtf.org>
References: <20100225054546.16850.qmail@simone.iecc.com>
In-Reply-To: <20100225054546.16850.qmail@simone.iecc.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Feb 2010 06:22:39.0490 (UTC) FILETIME=[EE126620:01CAB5E2]
Subject: Re: [Asrg] Summary of junk button discussion
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: Thu, 25 Feb 2010 06:20:36 -0000

On 2/25/2010 12:45 AM, John Levine wrote:

> The only think other than a junk button that appears useful is a
> not-junk button to display when looking at stuff in a junk folder.  I
> suppose we could do that, but then we'd have to define what a junk
> folder is.

Not really.

Thunderbird has a junk button that toggles a "junk" flag on or off per 
email, without tying it to folders.  You can define additional actions 
as to what happens when you hit junk (move to junk folder or delete). 
And undo it.  While it's specifically tied to Bayesian training in the 
client, it doesn't really have to be.  And by fairly trivial extension, 
you could add a "FBL to <x@y>" action, default perhaps supplied by MDA 
header.

[The bayesian filtering will set the junk flag, and the actions aren't 
necessarily identical to when you explicitly mark something junk.]

Later versions of Tbird have yet another "state" - "I dunno if this is 
junk" (I think.  Probably an intermediate Bayesian score).  Which makes 
things a bit more awkward - marking something not-junk from that state 
can be tricky if you have "move marked junk to junk folder" set because 
it toggles thru "junk" first.  But that's a Bayesian implementation 
artifact/feature I think.

With more tweaking, such an implementation would be a bit more 
user-friendly, and can stand as a guide as to how you might spec out 
what the junk/unjunk button "means", and leave actions to the 
implementation.