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

Alessandro Vesely <> Tue, 09 February 2010 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D3A93A73B3 for <>; Tue, 9 Feb 2010 07:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.609
X-Spam-Status: No, score=-4.609 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3lLH8nuvTvMS for <>; Tue, 9 Feb 2010 07:55:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9E9713A7221 for <>; Tue, 9 Feb 2010 07:55:27 -0800 (PST)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by with ESMTPSA; Tue, 09 Feb 2010 16:56:33 +0100 id 00000000005DC039.000000004B7185B1.00005FB3
Message-ID: <>
Date: Tue, 09 Feb 2010 16:56:33 +0100
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Generally workable ways of adding a spam button to MUAs
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Feb 2010 15:55:28 -0000

On 09/Feb/10 13:08, Ian Eiloart wrote:
> --On 8 February 2010 16:44:18 +0100 Alessandro Vesely <> 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.