Re: [Asrg] Summary of junk button discussion

Alessandro Vesely <vesely@tana.it> Fri, 26 February 2010 12:20 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 6280428C10E for <asrg@core3.amsl.com>; Fri, 26 Feb 2010 04:20:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.602
X-Spam-Level:
X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 H5E2fWGugqAE for <asrg@core3.amsl.com>; Fri, 26 Feb 2010 04:20:26 -0800 (PST)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id ABA1128C1A6 for <asrg@irtf.org>; Fri, 26 Feb 2010 04:20: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, 26 Feb 2010 13:22:32 +0100 id 00000000005DC037.000000004B87BD08.00003381
Message-ID: <4B87BD07.9000502@tana.it>
Date: Fri, 26 Feb 2010 13:22:31 +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: <20100225054546.16850.qmail@simone.iecc.com> <4B86172D.2080702@nortel.com> <4B86AD93.1050800@tana.it> <4B86DD80.8060508@nortel.com>
In-Reply-To: <4B86DD80.8060508@nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 26 Feb 2010 12:20:29 -0000

On 25/Feb/10 21:28, Chris Lewis wrote:
> On 2/25/2010 12:04 PM, Alessandro Vesely wrote:
>> On 25/Feb/10 07:22, Chris Lewis wrote:
>>> 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.
>
>> I don't think John meant a "general" definition here... :-/
>
> John seemed to be implying you can't have a "non-junk" button without a junk folder (eg: in an IMAP sense).

That seems reasonable...

> I was just pointing out Thunderbird's "not junk" implementation, which is functional independent of the existence of any kind of foldering mechanism, IMAP or otherwise.

Yup. The JunQuilla extension makes that even more manageable. It is an 
interactive tool running on the end-user's box, though.

> Heck, SpamAssassin even manages to tune Bayesian without having any end-user feedback at all.

I never adventured into such esoteric settings. Are there howtos or 
any docs about it?

>> To recap, junk buttons can be embedded within a more sophisticated
>> architecture (as for IMAP). But not the other way around: anti-spam
>> filter training cannot (in general) be based upon junk buttons and
>> abuse reporting.
>
> Of course you can train spam filters based on abuse reports. We've been
> doing precisely that for 13 years in several different incarnations.

Hm... I've been tinkering with my server's settings based on users' 
reports as well, but not automatically. There are various mechanisms, 
e.g. Vipul's Razor, that allow users to share their verdicts about the 
spamminess of a given message. However, in order to attach to junk 
buttons a meaning of "filter messages /like/ this" we would need to 
define what that means in rather unambiguous terms.

> It may well make sense to include an "tickle IMAP" server as part of a
> spec, but, also having an abuse reporting mechanism makes sure that you
> have just about all implementations covered, IMAP or otherwise.
>
> We could spec both, and leave it up to an installation or user to decide
> which (or both) to use in any particular instance.

I'd lean toward specifying just how to deliver abuse reports. Neither 
junk buttons nor their color should be mandated.