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

"Chris Lewis" <> Tue, 09 February 2010 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 035BC3A75A0 for <>; Tue, 9 Feb 2010 10:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.461
X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 Wdyg72QZSAiF for <>; Tue, 9 Feb 2010 10:28:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BA07C3A7593 for <>; Tue, 9 Feb 2010 10:28:21 -0800 (PST)
Received: from ( []) by (Switch-2.2.0/Switch-2.2.0) with ESMTP id o19ITPI06990 for <>; Tue, 9 Feb 2010 18:29:25 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 13:29:24 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 9 Feb 2010 13:29:24 -0500
Message-ID: <>
Date: Tue, 9 Feb 2010 13:29:01 -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 18:29:24.0653 (UTC) FILETIME=[CE2A3DD0:01CAA9B5]
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 18:28:23 -0000

Alessandro Vesely wrote:
> On 09/Feb/10 17:45, Steve Atkins wrote:
>> On Feb 9, 2010, at 8:32 AM, Alessandro Vesely wrote:
>>>  There's a whole theory of other ARF messages that may arrive at a domain's abuse@ mailbox. A domain's user, or someone writing to a forwarded address of that domain, writes a message that is reported as spam, either correctly or by mistake. As part of an FBL or other trust-chain, the message comes back wrapped in an ARF report at the apparently originating domain.
>>>  The mailbox is abuse@domain in both cases. Although it may seem desirable to have different addresses for incoming and outgoing reports, I doubt such distinction will ever be effective. Indeed, the forwarded case is ambiguous.
>> If you think that any part of this chain is involving mail sent to abuse@ anywhere your model of it is a long way from how I understand the situation.
> The abuse-mailbox is an attribute in some whois db (e.g. RIPE). The 
> 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.

Do NOT assume that TiS buttons have anything to do whatsoever with 
RFC2142, standardized role accounts, or whois "abuse-mailbox" entries.

Filter tuning doesn't, nor do FBLs (ARF'd or otherwise).  While abuse@ 
_may_ get derivations of TiS reports via ARF in some specific cases that 
are pre-arranged in advance, in no sense should we encourage such role 
accounts to be target for a raw MUA (or even MTA) stream of complaints.

> I agree that's a possibility. I've proposed abuse@authserv-id, which 
> may or may not be simpler. I don't think it makes a big difference.

@authserv-id may well be a good idea, but _not_ to "abuse" or any other
pre-existing role account intended, as in the old way, for human 

> Yes, but I've used for the FBL(s) I've subscribed to. 
> Perhaps if I had a ponderous ARF traffic I'd be better off using a 
> different address. However, that would be more of a nuisance if then 
> I'd have to redirect there other ARF messages that somehow reach the 
> abuse mailbox instead of my dedicated address.

It'd be more than a nuisance if the standard forces a one-size-fits-all 
targetting of all MUA-generated ARFs at abuse@everywhere.

Best to simply not go there.