Re: [Asrg] Generally workable ways of adding a spam button to MUAs

Ian Eiloart <iane@sussex.ac.uk> Tue, 09 February 2010 16:30 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 808D128C11F for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 08:30:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level:
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, 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 pTt0Chw9bhfT for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 08:30:50 -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 108BF3A73F8 for <asrg@irtf.org>; Tue, 9 Feb 2010 08:30:42 -0800 (PST)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.135.133]:49950) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KXL1XZ-0004HM-ET for asrg@irtf.org; Tue, 09 Feb 2010 16:32:23 +0000
Date: Tue, 09 Feb 2010 16:31:46 +0000
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <9C0630543F31EF72B020CF3A@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <4B7185B1.9010002@tana.it>
References: <20100205152046.87683.qmail@simone.iecc.com> <A57020F253FEFC9A8ED39F50@lewes.staff.uscs.susx.ac.uk> <4B703152.3070905@tana.it> <3F4D6869A3889A28035DEE70@lewes.staff.uscs.susx.ac.uk> <4B7185B1.9010002@tana.it>
Originator-Info: login-token=Mulberry:01lVoDof67cQbWx1cDAYAIz3YU+9Ik+/iACsU=; 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] Generally workable ways of 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: Tue, 09 Feb 2010 16:30:51 -0000

--On 9 February 2010 16:56:33 +0100 Alessandro Vesely <vesely@tana.it> 
wrote:

> On 09/Feb/10 13:08, Ian Eiloart wrote:
>> --On 8 February 2010 16:44:18 +0100 Alessandro Vesely <vesely@tana.it>
>> wrote:
>>> Problem A: report spam for complaining (was #3)
>>>
>>> Problem B: tune servers' filters (was #2)
>>>
>>> I don't think it's useful to try and solve both of them at the same
>>> time.
>>
>> I'm completely confused by this message. I really don't understand at
>> all what it is that you're saying. Problem B is about how you handle
>> reports once you have them. I don't understand what "Problem A: report
>> spam for complaining" means at all.
>
> Problem B imposes a tight matching between where the original message has
> been filter and where the report is going to be handled. In addition, it
> needs both spam and ham info. Since the main purpose of server-based (as
> opposed to client-based) filtering is to save bandwidth, efficiency is a
> relevant concern.
>
> Problem A has a somewhat wider horizon, as it assumes that reported spam
> may be routed through some trust-chained operators, possibly reaching the
> author of the original message. Although the report may also be used for
> tuning or assessing anti-spam filters, its main purpose is to affect the
> source of the original message. This is a generalization --and
> regularization-- of the FBLs currently used between giant mailbox
> providers and ESPs. My expectation is that it will result in important
> advances in the collective understanding of spam, so that massive abuse
> reporting will not be needed forever. In the latter respect, relatively
> inefficient (inelegant) procedures may be acceptable, if they widen the
> chances of adoption.
>
> Hope this clarifies my point, sorry for the unintended confusion.

Yes, that's helpful. You've identified a different dimension in which we 
could divide the large problem (reporting junk mail). That is: the purpose 
to which the report might be applied.

I think that's the third possible dimension that we've identified:

a) purpose (your distinction), reporting up chain would probably require 
SMTP reports, but they could be generated in response to the flagging or 
labelling of messages on mailstores.
b) who's in control (the user or the operator), which bears upon whether to 
use SMTP for reporting.
c) the nature of the mailstore (POP or IMAP), which bears upon the space of 
possible reporting mechansims.


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