Re: [Asrg] Consensus Call - submission via posting (was Re: Iteration #3)

Ian Eiloart <iane@sussex.ac.uk> Wed, 10 February 2010 12:22 UTC

Return-Path: <iane@sussex.ac.uk>
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 A46AB3A73CC for <asrg@core3.amsl.com>; Wed, 10 Feb 2010 04:22:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.279
X-Spam-Level:
X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
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 mF5t2M3b8EKw for <asrg@core3.amsl.com>; Wed, 10 Feb 2010 04:22:09 -0800 (PST)
Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id B67DF28C1D4 for <asrg@irtf.org>; Wed, 10 Feb 2010 04:21:55 -0800 (PST)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.135.133]:54351) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KXML3L-0006O0-P1; Wed, 10 Feb 2010 12:23:46 +0000
Date: Wed, 10 Feb 2010 12:23:05 +0000
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Jose-Marcio.Martins@ensmp.fr, Anti-Spam Research Group - IRTF <asrg@irtf.org>, dcrocker@bbiw.net
Message-ID: <5E6E00B6524D6B3BCD76E413@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <4B71B2E4.2060103@ensmp.fr>
References: <4B6C6D35.1050101@nortel.com> <4B6D41E3.8000209@tana.it> <4B6DAD0C.3020109@nortel.com> <4B6DB6D1.5050805@dcrocker.net> <4B71B2E4.2060103@ensmp.fr>
Originator-Info: login-token=Mulberry:01Fs/kvX8wUiJXPDgfgvWJRFcwfEcFF3n1izo=; token_authority=support@its.sussex.ac.uk
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
Subject: Re: [Asrg] Consensus Call - submission via posting (was Re: Iteration #3)
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: Wed, 10 Feb 2010 12:22:10 -0000

--On 9 February 2010 20:09:24 +0100 Jose-Marcio Martins da Cruz 
<Jose-Marcio.Martins@ensmp.fr> wrote:

>
> But I (and surely others) have another requirement. It could be
> interesting to use this mechanism in an active learning context. That
> means, user can receive the message flagged as "label required". So the
> feedback should include the information : ham/spam.
>

Yes, the content of the report remains to be discussed. If we were able to 
go down the route of labelling the message on the mailstore, I'd like to 
see a rich set of messages available for two way information flow, 
including the following meanings:

The server filter thinks this message is junk.
The server filter thinks this message is not junk.
The MUA filter thinks this message is junk
The MUA filter thinks this message is not junk
The user has asserted that this message is unwanted
The user has asserted that this message is wanted
The user has asserted that this message is reportable

Perhaps probabilities could be associated with filter results, too.

<AGENT> asserts with <LIKELIHOOD> that this message is <JUNK/NOT 
JUNK/PHISH/etc> because <REASON>

Where AGENT might be the userid of the user applying the report, or the 
name of the filter software (eg spamassassin, mail.app, thunderbird).

LIKELIHOOD could be based on a spamassassin score or a bayesian analysis.

REASONs could be filter rules (eg spamassassin hits), free text applied by 
the user, etc.

Thus, the mechanism could be used to give very specific information to 
users, or to operators.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/