Re: [Asrg] ARF traffic, was Spam button scenarios

Alessandro Vesely <vesely@tana.it> Wed, 10 February 2010 09:37 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 CC9BF3A6C92 for <asrg@core3.amsl.com>; Wed, 10 Feb 2010 01:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.603
X-Spam-Level:
X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
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 vie1PL1cNW6Q for <asrg@core3.amsl.com>; Wed, 10 Feb 2010 01:37:17 -0800 (PST)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id AF0D328C0DD for <asrg@irtf.org>; Wed, 10 Feb 2010 01:37:17 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 10 Feb 2010 10:38:23 +0100 id 00000000005DC038.000000004B727E8F.000025F9
Message-ID: <4B727E8F.4060200@tana.it>
Date: Wed, 10 Feb 2010 10:38:23 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: asrg@irtf.org
References: <20100208150513.49394.qmail@simone.iecc.com> <0BF553ABE600903AE55F0E89@lewes.staff.uscs.susx.ac.uk> <4B718E2A.5070304@tana.it> <D0AC3DDE-3995-4EE9-9914-30E2831BAE22@blighty.com> <4B71A3D8.40401@tana.it> <4B71A96D.8060909@nortel.com> <4B71B575.7050107@tana.it> <6B755324-E7B2-4EE3-B059-35FD0F74EDA7@blighty.com>
In-Reply-To: <6B755324-E7B2-4EE3-B059-35FD0F74EDA7@blighty.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [Asrg] ARF traffic, was Spam button scenarios
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, 10 Feb 2010 09:37:18 -0000

On 09/Feb/10 20:25, Steve Atkins wrote:
> You (and others) are obsessing about the MIME format of inbound email, which is something of a scarlet fish.
>
> What you need to be able to identify is who sent it to you, for what purpose, under what agreement and what you need to do with the data in it.

Correct. I just implied that the "To" header field may not be the most 
convenient data item for identifying the processing that a report 
deserves. IMHO, until we have a handful of FBLs it may be a good 
practice to cleverly partition each one using different addresses as 
labels. However, if they become several dozens, we'd probably better 
off classifying them by type rather than by agreement.

Let me try and fantasize about possible actions our handler may take, 
besides assessing filters and adjusting reputations, which are always 
possible.

Stratum 0 reports come from TiS buttons. We feed FBLs, including our 
internal FBL --i.e. check if we host the sender.

Stratum 1 reports come from subscribed FBLs. We check whether the 
original message had been sent through our MSA, in this case we apply 
relevant policies. However, we might have just forwarded the original 
message, or be anyhow involved in some trust chain. We can drop those 
reports, or we can generate stratum 2 ones.

It seems that in any case we should check whether our MSAs can be 
blamed for the original message. In case, we apply policies; that is, 
we implicitly acknowledge the report. IMHO, it may be worth to provide 
for error checking here, unless there is an overwhelming number of 
unanimous reports: if the author appeals claiming that the TiS button 
had been pushed by mistake, and her reputation is good, possibly ask 
the recipient(s) to double check it. Only when sender and recipient(s) 
(definitively) disagree, the relevant abuse teams will have to 
manually inspect the original message (and punish the guilty.)

If our MSAs are not responsible for having injected the original 
message into the mail system, we should check if we have a trust 
relationship leading to the Reported-Domain. Perhaps it is convenient 
to use the stratum data, or other agreement characteristics, as 
weights for finding a minimum spanning tree. At any rate, the problem 
of reaching a trusted domain through a trust chain can be stated 
independently of how trust relationships are established.

If the Reported-Domain is not trusted, the report should be delivered 
to the relevant connection provider, à la Abusix. It is an isolated 
MTA or a bot.