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

"Chris Lewis" <> Tue, 09 February 2010 22:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE0A53A7633 for <>; Tue, 9 Feb 2010 14:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.46
X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U7RAK+wAsvJt for <>; Tue, 9 Feb 2010 14:51:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C284C3A7631 for <>; Tue, 9 Feb 2010 14:50:59 -0800 (PST)
Received: from ( []) by (Switch-2.2.0/Switch-2.2.0) with ESMTP id o19Mq4I05619 for <>; Tue, 9 Feb 2010 22:52:04 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 17:52:03 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 9 Feb 2010 17:52:03 -0500
Message-ID: <>
Date: Tue, 9 Feb 2010 17:51:40 -0500
From: "Chris Lewis" <>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Lightning/0.9 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Feb 2010 22:52:03.0781 (UTC) FILETIME=[7F565750:01CAA9DA]
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: Tue, 09 Feb 2010 22:51:00 -0000

Alessandro Vesely wrote:
> On 09/Feb/10 19:29, Chris Lewis wrote:
>> Alessandro Vesely wrote:
>>> form abuse@domain is standardized by rfc 2142. Some people (e.g.
>>> Abusix) may plan to send machine generated complaints at such addresses.
>> And they'll learn very very soon that that doesn't work.
>> Been there/done that in a limited fashion, and even in that limited
>> fashion, it don't work.
> Why not, _what_ goes wrong?

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. is for reports of abuse originating _at_, not for reports of abuse (eg: spam) originating 
elsewhere that's users want to report.

In other words, our TiS should _not_ go to  It goes 
elsewhere.  If I changed my mind for convenience, I wouldn't change the 
TiS to go to, I'd change the mail system to alias it.

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.

> It seems to me that a simple filter could determine ARF/non-ARF 
> quality of a message in a fraction of the time that spamassassing 
> would take to process it, assuming abuse@ boxes are whitelisted.

A single bot run could fill up the abuse box so quickly that a "simple 
filter" can't do anything about it.

For the rare occasion that you want your TiS button goes to abuse@<you>,
a simple forwarding alias is far easier than the more common 
circumstance of having to construct some sort of content filter to split 
ARFs from non-ARFs.  And less likely to completely break down during a