Re: [Asrg] "Mythical" Global Reputation System

Alessandro Vesely <vesely@tana.it> Tue, 15 December 2009 18:42 UTC

Return-Path: <vesely@tana.it>
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 E56913A68F1 for <asrg@core3.amsl.com>; Tue, 15 Dec 2009 10:42:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.22
X-Spam-Level:
X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-2.401, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 KIckljCskRp9 for <asrg@core3.amsl.com>; Tue, 15 Dec 2009 10:42:29 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 38D6E3A6A22 for <asrg@irtf.org>; Tue, 15 Dec 2009 10:42:29 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 15 Dec 2009 19:42:09 +0100 id 00000000005DC031.000000004B27D881.00002B42
Message-ID: <4B27D881.8050905@tana.it>
Date: Tue, 15 Dec 2009 19:42:09 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <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>
In-Reply-To: <20091212153130.GG24477@verdi>
Content-Type: text/plain; charset="us-ascii"; 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: Tue, 15 Dec 2009 18:42:31 -0000

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

Agreed :-)

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

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

Botnet spam shouldn't be reported. 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, if 
we didn't know the answer: vouching. When whitelisting will work well, 
postmasters will be able to lower their spam thresholds without fear 
of FPs.

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

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

>> * "Relationship between vouching and reputation services." Vouching 
>>   must clearly be based on reputation.
> 
>    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.

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

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?

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

But how is that different from a reputation tracker?

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

Yes. We won't catch professional spammers this way. We need to catch 
the good guys that occasionally fall into temptation. Numerically, it 
is a minimal part of spam, because most spam comes from botnet 
operators. Think of it as a sombrero-shaped pitch surface centered on 
ham: we want to block the neighborhood just outside the ham boundary, 
so that we can whitelist that region.

>    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. It may or may not be worth 
to avoid list washing capabilities by trying to protect the reporter's 
address; 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.)

>    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. Maybe individual users deserve 
the right to appeal against a block, _they_ may want to know who 
reported what message as spam...

I agree a vouching service may cash a fee from the mail domain they 
vouch for. This does not imply corruption, though.

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

An obvious workaround for a mailbox provider who has to block a user 
is to provide an alias. It should be forbidden. However, it is 
difficult to track it. Statistical data or sample audits may help to 
withdraw vouching for fraudulent operators.

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.