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

Steve Atkins <steve@blighty.com> Tue, 09 February 2010 17:48 UTC

Return-Path: <steve@blighty.com>
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 9BE0B28C228 for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 09:48:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.459
X-Spam-Level:
X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, 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 VPuqIIGtLWu8 for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 09:48:40 -0800 (PST)
Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id C73203A7451 for <asrg@irtf.org>; Tue, 9 Feb 2010 09:48:40 -0800 (PST)
Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 1A61080A98 for <asrg@irtf.org>; Tue, 9 Feb 2010 09:49:48 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
From: Steve Atkins <steve@blighty.com>
In-Reply-To: <E90C946DC73DE1833D069DD2@lewes.staff.uscs.susx.ac.uk>
Date: Tue, 9 Feb 2010 09:49:47 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDDB199D-DEF2-4D60-9AFE-F1651A50FE3B@blighty.com>
References: <20100208150513.49394.qmail@simone.iecc.com> <0BF553ABE600903AE55F0E89@lewes.staff.uscs.susx.ac.uk> <4B718E2A.5070304@tana.it> <E90C946DC73DE1833D069DD2@lewes.staff.uscs.susx.ac.uk>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
X-Mailer: Apple Mail (2.1077)
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: Tue, 09 Feb 2010 17:48:41 -0000

On Feb 9, 2010, at 9:38 AM, Ian Eiloart wrote:

> 
> 
> --On 9 February 2010 17:32:42 +0100 Alessandro Vesely <vesely@tana.it> wrote:
> 
>> On 09/Feb/10 16:11, Ian Eiloart wrote:
>>> The user retrieves a message from our mailstore, and attempts to use an
>>> address in our domain to report it to us, but submitted through a third
>>> party MSA. We'll simply reject the message on the basis that we don't
>>> permit such traffic onto our MX servers. We won't even look at the
>>> message body.
>> 
>> 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.
>> 
>> A mail domain worth its salt should be able to recognize if the original
>> message had been mailed out from its premises, and who is its blamed
>> author or sender. Policies spell out sequent actions.
> 
> That's right. We're talking about messages with a sender address in our domain, that were NOT sent using our MSA. We don't permit that. We'll reject the message.
> 
> Actually, I think I said we won't look at the message, but that's not right. We check the message headers to identify messages that were originally routed through the MSA. For abuse reports from our domain, though, they're not going to go out of our system and back again.

This is nothing to do with abuse reports, though, nor mail sent to abuse@ anywhere. It's mail to a specific special address used solely for TiS notifications.

Even in a setup such as yours with strange rules for general mail delivery, it'd be possible to special case that specific special address should you choose to do so. (In fact it would likely be in an entirely different domain, making that easy to do).

Cheers,
  Steve