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

Alessandro Vesely <> Wed, 10 February 2010 09:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 968163A76A2 for <>; Wed, 10 Feb 2010 01:55:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.602
X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hJTgTu84huvo for <>; Wed, 10 Feb 2010 01:54:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 88F5C3A76A1 for <>; Wed, 10 Feb 2010 01:54:59 -0800 (PST)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by with ESMTPSA; Wed, 10 Feb 2010 10:56:08 +0100 id 00000000005DC039.000000004B7282B8.0000755E
Message-ID: <>
Date: Wed, 10 Feb 2010 10:56:08 +0100
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] ARF traffic, was Spam button scenarios
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: Wed, 10 Feb 2010 09:55:00 -0000

On 09/Feb/10 23:51, Chris Lewis wrote:
> The extant methods for determining where abuse reports are (a) usually
> wrong or missing and we're not going to bail that ocean, (b)
> insufficiently granular (both report types, but worse, breakdowns of
> space to responsible parties, ie resellers) and (c) without aggregation,
> too high volume even for automation.

You probably meant "where to send" or "where to receive", which makes 
(a) ambiguous.

For (b), the responsible party --the list controller-- is generically 
referred to as "the user". However, if they are reseller, it may be 
convenient to treat them as if they where a (trusted) domain and just 
resend ARF reports to them. We should check they apply agreed upon 

Aggregation is more subtle, unless it's done for copies of the same 
message. If reports are used for unsubscribing, a list is needed 
anyway. Would you make an attachment to the ARF report?

> is for reports of abuse originating _at_
>, not for reports of abuse (eg: spam) originating
> elsewhere that's users want to report.

Agreed. From a user's perspective, though, the abuse originates at the 
inbox provides :-/

> I did some experimentation with automatic aggregation and
> hand-configured destinations for a small fraction of reports. That
> worked somewhat, but not worth the effort to keep touching the config.

Couldn't that result from a clever algorithm and an automatically 
maintained database?