Re: [Asrg] "Mythical" Global Reputation System

Alessandro Vesely <vesely@tana.it> Sat, 12 December 2009 09:57 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 AF9CE3A68E3 for <asrg@core3.amsl.com>; Sat, 12 Dec 2009 01:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.034
X-Spam-Level:
X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
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 dI6x+rdLBH+E for <asrg@core3.amsl.com>; Sat, 12 Dec 2009 01:57:51 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id C92A53A65A5 for <asrg@irtf.org>; Sat, 12 Dec 2009 01:57:50 -0800 (PST)
Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 12 Dec 2009 10:57:31 +0100 id 00000000005DC033.000000004B23690B.00003F52
Message-ID: <4B236972.5080903@tana.it>
Date: Sat, 12 Dec 2009 10:59:14 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20091211011855.13454.qmail@simone.iecc.com> <4B21DE58.6090901@mail-abuse.org> <20091211144149.GF24477@verdi> <4B227928.4030002@mail-abuse.org>
In-Reply-To: <4B227928.4030002@mail-abuse.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] "Mythical" Global Reputation System
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: Sat, 12 Dec 2009 09:57:51 -0000

Let me try and summarize the topics we are concerned about.

* "Assess operator's policy enforcement." IMHO, the primary product 
of feedback processing is to tell how cleverly an operator blocks 
reported spammers. However, an operator could lie, which is why we 
need the other topics.

Douglas Otis wrote:
> On 12/11/09 6:41 AM, John Leslie wrote:
>> Douglas Otis<dotis@mail-abuse.org>  wrote:
>>     I remain convinced that senders need an established relationship
>> with vouching services and receivers need an established relationship
>> with reputation services, and that the interaction between these two
>> types of services is an area for interesting work.

* "Relationship between vouching and reputation services." Vouching 
must clearly be based on reputation. Why should it be a separate 
service, and what are the relationships between them and with mail 
operators?

> The focus could be more on vetting feedback sources directed to the 
> postmasters using _blind_ addresses, rather than assessing each 
> individual message, and have a centralized feedback system that 
> publishes related metrics and sender's specific information, such as 
> their volumes, their purported types of messages, and their directly 
> verifiable sources such as hostnames or DKIM signatures.  The direct 
> information assists in establishing correctly attributed feedback.

* "Reliable feedback paths." This includes vetting sources, 
assessing operators, and establishing minimal authentication 
requirements for exchanging abuse reports.

* "Senders' generic profiling." A rather slippery slope, because we 
don't want to break anonymity nor privacy. But we need some metrics 
to identify "sockpuppetry" (or whatever we'd want to call multiple 
5322.From operated by a single individual/entity.)

Thus far, I've counted four topics. Did I forget or overgeneralize any?

If we want an ASRG subgroup, it is useful to pinpoint what we would 
use it for. To know where we are and what can we shoot for is 
obviously interesting anyway.