Re: [Asrg] "Mythical" Global Reputation System

John Leslie <john@jlc.net> Sat, 12 December 2009 15:31 UTC

Return-Path: <john@jlc.net>
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 7AF563A688F for <asrg@core3.amsl.com>; Sat, 12 Dec 2009 07:31:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.254
X-Spam-Level:
X-Spam-Status: No, score=-6.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, 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 iCTPZxJntKZH for <asrg@core3.amsl.com>; Sat, 12 Dec 2009 07:31:43 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 268243A6778 for <asrg@irtf.org>; Sat, 12 Dec 2009 07:31:43 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 10EA133C56; Sat, 12 Dec 2009 10:31:30 -0500 (EST)
Date: Sat, 12 Dec 2009 10:31:30 -0500
From: John Leslie <john@jlc.net>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <20091212153130.GG24477@verdi>
References: <20091211011855.13454.qmail@simone.iecc.com> <4B21DE58.6090901@mail-abuse.org> <20091211144149.GF24477@verdi> <4B227928.4030002@mail-abuse.org> <4B236972.5080903@tana.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B236972.5080903@tana.it>
User-Agent: Mutt/1.4.1i
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 15:31:44 -0000

Alessandro Vesely <vesely@tana.it> wrote:
> 
> 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.

   It's not that simple, IMHO.

   Firstly, "reporting" of spammers is badly broken. If the only thing
you do is react to spam reports, your reputation is likely to be damaged
before the first report arrives.

   Secondly, the botnet problem is endemic. It's nearly impossible to
avoid having some ISP customers (or even enterprise users) let their
computers be infected and become part of a botnet. Blocking outgoing
port 25 helps, but it's very hard to catch botnet spam going through
your "standard" MTA before hundreds have gone out; and some botnet
operators are skilled at staying below your radar.

   Thirdly, fixing botnet-infected computers is insanely expensive to
ISPs _and_ enterprises, while botnet re-infection rates are scary.

> However, an operator could lie, which is why we need the other topics.

   I don't think we _can_ enumerate all the components of reputation
that matter. Certainly, tendency to mis-state policies and enforcement
matters a lot...

> Douglas Otis wrote:
>> On 12/11/09 6:41 AM, John Leslie 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.

   Vouching based _solely_ on reputation is useless, IMHO.

   Vouching should be based on more immediate knowledge: are there
policies in place that satisfy the vouching service? What is the record
of enforcement of those policies? What measure do you have of "normal"
traffic for the sender you're vouching for?

>   Why should it be a separate service, and what are the relationships
>   between them and with mail operators?

   Vouching should be a separate service so that the relationship with
the (sending) customer isn't compromised. Different vouching services
should be able to vouch for different characteristics: percentage or
volume of emails considered abusive, responsiveness, etc...

>> 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.

   This is another item a vouching service might include: number or
percentage of emails received at spamtraps. Doug has a point here:
spam-reporting is _so_ broken that vouching services starting business
today probably would need a network of spamtraps to get useful reports.

   But IMHO spamtraps are not a viable long-term measure. It's too
easy to find out where a spamtrap is and ensnare an innocent MTA to
send something to it. (Some spamtraps can trigger on NDNs _required_
by the SMTP RFCs.)

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

   Vetting spam-report sources is _hard_. Ideally, the reports would
contain enough information, and you'd have access to enough logged
information, to verify that such a message was indeed sent by the
customer of the vouching service.

   At first blush, that would seem sufficient to qualify the message
as spam, and your customer should agree to stop sending such messages
to that recipient. But of course you won't _get_ enough information
to say _what_ message and _what_ recipient without an established
trust level between reporter and vouching service...

   There's a delicate balance here, where a vouching service needs to
first satisfy its customer (the sender) and secondly assure the
reporter that it can be trusted with enough information to be useful.

> * "Senders' generic profiling." A rather slippery slope, because we 
>   don't want to break anonymity nor privacy.

   I don't believe this is a function for vouching services, but
rather a function for reputation services that don't have an
established relationship with the sender.

   IMHO the presence of vouching services reduces the need for sender
profiling.

--
John Leslie <john@jlc.net>