Re: [Asrg] "Mythical" Global Reputation System

Douglas Otis <dotis@mail-abuse.org> Wed, 16 December 2009 00:15 UTC

Return-Path: <dotis@mail-abuse.org>
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 C6D223A6A9E for <asrg@core3.amsl.com>; Tue, 15 Dec 2009 16:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.151
X-Spam-Level:
X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=0.448, 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 ZTCZuYI4cdrk for <asrg@core3.amsl.com>; Tue, 15 Dec 2009 16:15:08 -0800 (PST)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 67A2A3A67AA for <asrg@irtf.org>; Tue, 15 Dec 2009 16:15:08 -0800 (PST)
Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 40C81A9443B for <asrg@irtf.org>; Wed, 16 Dec 2009 00:14:50 +0000 (UTC)
Message-ID: <4B282679.2080609@mail-abuse.org>
Date: Tue, 15 Dec 2009 16:14:49 -0800
From: Douglas Otis <dotis@mail-abuse.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: asrg@irtf.org
References: <20091211011855.13454.qmail@simone.iecc.com> <4B21DE58.6090901@mail-abuse.org> <20091211144149.GF24477@verdi> <4B227928.4030002@mail-abuse.org> <4B236972.5080903@tana.it> <20091212153130.GG24477@verdi> <4B27D881.8050905@tana.it> <20091215194641.GJ24477@verdi>
In-Reply-To: <20091215194641.GJ24477@verdi>
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: Wed, 16 Dec 2009 00:15:09 -0000

On 12/15/09 11:46 AM, John Leslie wrote:
> Alessandro Vesely<vesely@tana.it>  wrote:
>> John Leslie wrote:
>>
>> This can be fixed by pushing, perhaps. Reporting huge quantities of
>> spam may eventually move abuse-box operators.
>
>     I have no objection to you trying that...
>
>     But I'd like to have a vouching service warn me _before_ I receive
> any "abuse@" emails.

John,

A problem that needs solving is defending specific feedback addresses. 
Bad actors will abuse email addresses intended for reporting abuse or 
contacting the postmaster.  While a vouching service can provide the 
desired feedback through indirect means, so can a feedback conduit service.

This service can:

a) Consolidate abuse feedback and limit the information exchanged.

b) Selectively allow blocking of feedback sources.


To obtain the service, users would allow their domain metrics to be 
published covering:

1) The amount of feedback obtained from "spam" reputation services.

2) The amount of account repeated feedback from "spam" reputation services.

3) The amount of feedback obtained from users "unwanted" email.

4) The amount of account repeated feedback from users "unwanted" email.

5) The amount of account and message volumes based upon message and 
volume specific feedback.

When more than 50% of senders blocked a source of "unwanted" email, it 
will not affect "unwanted" metrics.  It will also take 60 days before 
new "unwanted" email sources are included into the "unwanted" metrics.

[...]
>>> 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...
>>
>> But how is that different from a reputation tracker?
>
>     Reputation trackers lack the sender-supplied information we have
> discussed above.

This lost information could be replaced by having daily volume related 
feedback reporting.

>> When someone reports a message as spam, there are no concerns about
>> confidentiality of the message's content.
>
>     We need reports from folks who can't be bothered to agree or disagree
> with that.

Some protections can be achieved by using two categories of feedback. 
Feedback information primarily from spam-traps could be placed within 
the "spam" metrics.  Those whose feedback information is from user's use 
of "this is junk" buttons would be placed within the "unwanted" metrics.

>> It may or may not be worth to avoid list washing capabilities by trying
>> to protect the reporter's address;
>
>     This is why I want to have spam reports go to a reputation service
> which can satisfy (different) customen their privacy isn't compromised.
> (I don't know what it will take to satisfy everyone...)

IMHO, a service that offers a conduit for feedback should:

1) only accept signed feedback reports.

2) ensure the postmaster of the domain authorized the feedback for their 
specific domain.

3) only publish general metrics, and never any specific message content.

4) assume those running spam services also use ghost systems for their 
reputation assessments.

5) assume only those running spam services offer feedback suitable for 
"spam" metrics, where all other metrics would be described as "unwanted".

[..]
>> IMHO, a voucher who determines that spammers are not being blocked
>> should just withdraw vouching for the relevant mail domain --not doing
>> so would degrade its own reputation.
>
>     Agreed. There's a grey area in how long after a spam report is
> forwarded before withdrawing vouching -- or how many spam reports before
> withdrawing. This is why I envision a "vouching" report to say "incident
> in progress," encouraging receivers to give a temporary error.

There would be fewer accusations of being unfair by only publishing 
metrics and allowing receivers to make their own assessments.  Some will 
indeed want a binary indication of whether to block email, but that 
falls into the bailiwick of anti-spam service providers, who will then 
need to defend assessments that indicate no email should be accepted. 
Of course the conduit metrics will also need to be defended against 
being gamed.  As such, metrics from any specific source could ensure 
volumes do not change by more than a small percentage over any given 
period.  Although this will be controversial, senders could share lists 
of sources issuing false reports.

>> Maybe individual users deserve the right to appeal against a block,
>> _they_ may want to know who reported what message as spam...
>
>     This is what we need to get away from: appeals are just _too_
> expensive.

Publishing only metrics should avoid a need for handling appeals. Those 
being blocked would need to talk to the recipient blocking them.

>> I agree a vouching service may cash a fee from the mail domain they
>> vouch for. This does not imply corruption, though.
>
>     There are actual expenses involved in vouching. A fee is needed to
> cover these in most cases.

Running just a feedback conduit service, information gained might help 
assist other email related services that could offset the related costs. 
  Consolidating reports also helps defray network expenses, by utilizing 
input more than output directions.

-Doug