Re: [Asrg] "Mythical" Global Reputation System

Douglas Otis <> Fri, 11 December 2009 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1114B3A67A4 for <>; Fri, 11 Dec 2009 08:54:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.747, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B8ZcVZ2RrkB8 for <>; Fri, 11 Dec 2009 08:54:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2EF7B3A69FD for <>; Fri, 11 Dec 2009 08:54:20 -0800 (PST)
Received: from farside-dotis.local ( []) by (Postfix) with ESMTP id 63F56A94448 for <>; Fri, 11 Dec 2009 16:54:00 +0000 (UTC)
Message-ID: <>
Date: Fri, 11 Dec 2009 08:54:00 -0800
From: Douglas Otis <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
References: <> <> <20091211144149.GF24477@verdi>
In-Reply-To: <20091211144149.GF24477@verdi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] "Mythical" Global Reputation System
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: Fri, 11 Dec 2009 16:54:21 -0000

On 12/11/09 6:41 AM, John Leslie wrote:
> Douglas Otis<>  wrote:
>> On 12/10/09 5:18 PM, John Levine wrote:
>>> ... if you'd like to set up a reputation system subgroup, that
>>> would be fine.
>> Rather than a reputation system subgroup, something more along the line
>> of a legitimate senders clearing-house system which establishes
>> postmaster contacts, and tracks repeated feedback from vetted sources.
>     Neither John nor Doug should be surprised I'm still interested in
> reputation systems.
>     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.
>     Both services individually, IMHO, could be mostly automatic, with
> the reputation services receiving spam reports (presumably ARF format)
> and notifying the appropriate vouching service when these pass a
> threshhold set by the reputation service. (Passing the actual ARF
> reports to the vouching services would not necessarily be allowed.)

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.

The blind feedback address would need to verified with a ping-back from 
both the feedback address and that of the postmaster address, as a means 
to enable the feedback relay.  The system should also allow them to 
exclude sources of feedback sent to them and the level of consolidation, 
but this would not directly affect the metrics reported by the system. 
Such as repeated accounts, the number of unique signed feedback sources, 
reported volumes, and the number of message related feedbacks.

When a hostname is being relied upon for attribution, the system should 
report the addresses being used by that hostname with an upper limit of 
something like eight addresses.  Something as broad and nebulous as 
address lists can be heavily abused.  Those depending upon feedback 
vetted by hostnames need to ensure the hostname is within the indicated 
consistently used IP address range.  The postmaster should be able to 
directly publish this information, or allow the data to be gleaned, as 
not all sources will have established a contact.

>     We would need to formalize how reputation services discover the
> vouching service(s) related to specific senders, and it would help
> to formalize how to report a complaint threshhold being passed. In
> some cases, there should be sufficient trust between a reputation
> service and a vouching service to pass each individual ARF report,
> but IMHO this would not be the default case, and would need to be
> supported by reporting an action taken.

The relay system acting as a mindless intermediary could act as a type 
of assessment system, where metrics offer actionable information.  To 
keep metrics from being muddled, sources being heavily blocked would be 
excluded from published metrics.  There would also be a problem of 
detecting false "volume" assertions made by the sender, where this might 
be flagged by the number of unique feedback sources.  This suggests 
there might be a need for a daily volume report being feed back to the 
sender when more than N messages are received.  This might alert them to 
signature replay or hostname abuse.

>     I'm not sure about the need to formalize how vouching services
> discover the reputation services for particular receivers: I can
> imagine cases where receivers would not want that information public,
> and it's not obvious how this information would help.

Let the feedback speak for itself, and have a system that acts as a 
conduit for feedback offer actionable information. Publicly announcing 
feedback email-addresses is normally heavily abused.  This system needs 
to ensure feedback remains relatively clean and actionable, but it 
should not find itself making decisions about any specific message being 
spam or not.  Each receiver using the metrics being collected can then 
apply their own thresholds.  By allowing largely legitimate senders the 
ability to block feedback sources, excluding bad sources can be 
automatic, without any direct examination of messages.  If anything, 
there could be a promise to never examine any particular feedback 
message, with the exception of volume reporting.