Re: [Asrg] "Mythical" Global Reputation System

John Leslie <> Tue, 15 December 2009 19:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F90C3A6AA7 for <>; Tue, 15 Dec 2009 11:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.842
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7C3Z9b3Cv7+w for <>; Tue, 15 Dec 2009 11:47:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A06B63A6AFB for <>; Tue, 15 Dec 2009 11:46:55 -0800 (PST)
Received: by (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 <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <20091215194641.GJ24477@verdi>
References: <> <> <20091211144149.GF24477@verdi> <> <> <20091212153130.GG24477@verdi> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
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: Tue, 15 Dec 2009 19:47:16 -0000

Alessandro Vesely <> wrote:
> John Leslie wrote:
>> Alessandro Vesely <> 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.


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

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