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

Ian Eiloart <iane@sussex.ac.uk> Tue, 09 February 2010 17:37 UTC

Return-Path: <iane@sussex.ac.uk>
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 D8EAF28C169 for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 09:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.502
X-Spam-Level:
X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, 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 1ZUR32UVSrM8 for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 09:37:06 -0800 (PST)
Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id C1F4A28C145 for <asrg@irtf.org>; Tue, 9 Feb 2010 09:37:06 -0800 (PST)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.135.133]:53874) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KXL50P-000AKJ-D8 for asrg@irtf.org; Tue, 09 Feb 2010 17:38:49 +0000
Date: Tue, 09 Feb 2010 17:38:12 +0000
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <E90C946DC73DE1833D069DD2@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <4B718E2A.5070304@tana.it>
References: <20100208150513.49394.qmail@simone.iecc.com> <0BF553ABE600903AE55F0E89@lewes.staff.uscs.susx.ac.uk> <4B718E2A.5070304@tana.it>
Originator-Info: login-token=Mulberry:01ExhB23x5r0BUhZU9fz6GjbROeZBiNXY+iIM=; token_authority=support@its.sussex.ac.uk
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
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:37:07 -0000

--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.


-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/