Re: [Asrg] "Mythical" Global Reputation System

John Leslie <john@jlc.net> Tue, 15 December 2009 19:47 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 5F90C3A6AA7 for <asrg@core3.amsl.com>; Tue, 15 Dec 2009 11:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.842
X-Spam-Level:
X-Spam-Status: No, score=-3.842 tagged_above=-999 required=5 tests=[AWL=-2.143, BAYES_50=0.001, MANGLED_SPAM=2.3, 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 7C3Z9b3Cv7+w for <asrg@core3.amsl.com>; Tue, 15 Dec 2009 11:47:15 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id A06B63A6AFB for <asrg@irtf.org>; Tue, 15 Dec 2009 11:46:55 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 2E37733CAD; Tue, 15 Dec 2009 14:46:41 -0500 (EST)
Date: Tue, 15 Dec 2009 14:46:41 -0500
From: John Leslie <john@jlc.net>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <20091215194641.GJ24477@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> <20091212153130.GG24477@verdi> <4B27D881.8050905@tana.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B27D881.8050905@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: Tue, 15 Dec 2009 19:47:16 -0000

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

>> Secondly, the botnet problem is endemic...
> 
> Botnet spam shouldn't be reported...

   I don't agree. If one of my users is botted, I'd like to know it.
(Obviously, there are lazy operators who'd rather not know.)

> It shouldn't be accepted in the first place, which would have brought
> us back to the question of how does one tell a zombie's disposable
> mail domain from a regular one,

   I don't want _my_ MTA blacklisted because one of my users is botted:
I want to _seriously_ ration the damage he can do until he fixes it.

> if we didn't know the answer: vouching.

   But how does the receiving MTA know what vouching service to check?
And how does it know whether the vouching service is useful?

> When whitelisting will work well, postmasters will be able to lower
> their spam thresholds without fear of FPs.

   Agreed.

>> 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...
> 
> I've tried and depict it in 
> http://wiki.asrg.sp.am/wiki/Abuse_Reporting
> 
> The reputation tracker appears there in all its invisibility ;-)
> (There is also a tentative summary of the previous thread.)

   A worthy exercise! I hope it gets updated as the discussion continues.

>> Vouching based _solely_ on reputation is useless, IMHO.
> 
> Add the lapse of time that the mail domain has existed for, whether 
> its whois information is complete, and similar "easy" data.

   Be my guest... it still doesn't seem useful enough to me...

>> 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?
> 
> The policy that keeps jumping in my mind is "I'll ban you from sending 
> for N minutes times the number of abuse reports I get about you."

   A useful policy, easily implemented... but what qualifies as an
"abuse report" sufficient to enforce this? (The majority of reports I
receive concern spam that never touched my network, for example.)

> I don't know about "normal" traffic. Perhaps, there could be an ARF 
> field counting how many messages from a given IP a server got since 
> the previous abuse report?

   Potentially useful... but you need the sender to agree to release
this information to your vouching service...

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

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

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

> in such respect, it may have no sense to forward a report to both the
> sender _and_ its connection provider (steps 2 and 3 in the picture
> linked above.)

   AFAICT, most spam-receivers figure it makes no sense to report to
_either_ of these. :^(

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

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

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

>... 
> Providers who don't even know who their users are, are unable to block 
> them effectively. They are 2big2block, so vouching for them is useless 
> anyway.

   No provider is _always_ 2big2block! Some customers will want to avoid
blocking _some_ sending MTAs. That's a tussle for receiving providers
to work out with their customers. (And of course, nothing prevents a
reputation service from whitelisting "all" 2big2block senders...)

--
John Leslie <john@jlc.net>