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.
- Re: [Asrg] Spam button scenarios Steve Atkins
- [Asrg] Spam button scenarios John R. Levine
- Re: [Asrg] Spam button scenarios Daniel Feenberg
- Re: [Asrg] Spam button scenarios Ian Eiloart
- Re: [Asrg] Spam button scenarios Andreas Saurwein Franci Gonçalves
- Re: [Asrg] Spam button scenarios John Levine
- Re: [Asrg] Spam button scenarios Ian Eiloart
- Re: [Asrg] Spam button scenarios Alessandro Vesely
- Re: [Asrg] Spam button scenarios Ian Eiloart
- Re: [Asrg] Spam button scenarios John Levine
- Re: [Asrg] Spam button scenarios Derek Diget
- Re: [Asrg] Spam button scenarios Martijn Grooten
- Re: [Asrg] Spam button scenarios der Mouse
- Re: [Asrg] Spam button scenarios Bill Weinman
- Re: [Asrg] Spam button scenarios Chris Lewis
- Re: [Asrg] Spam button scenarios Seth
- Re: [Asrg] Spam button scenarios Steve Atkins
- Re: [Asrg] Spam button scenarios Martijn Grooten
- Re: [Asrg] Spam button scenarios John Levine
- Re: [Asrg] Spam button scenarios Ian Eiloart
- Re: [Asrg] Spam button scenarios Ian Eiloart
- [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Steve Atkins
- Re: [Asrg] ARF traffic, was Spam button scenarios Ian Eiloart
- Re: [Asrg] ARF traffic, was Spam button scenarios Steve Atkins
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Steve Atkins
- Re: [Asrg] ARF traffic, was Spam button scenarios Chris Lewis
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Steve Atkins
- Re: [Asrg] ARF traffic, was Spam button scenarios Chris Lewis
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Ian Eiloart
- Re: [Asrg] ARF traffic, was Spam button scenarios Ian Eiloart