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

Ian Eiloart <iane@sussex.ac.uk> Wed, 10 February 2010 12:42 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 B0F6C3A6B88 for <asrg@core3.amsl.com>; Wed, 10 Feb 2010 04:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.495
X-Spam-Level:
X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.948, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 sJYi+N8bzMT3 for <asrg@core3.amsl.com>; Wed, 10 Feb 2010 04:41:59 -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 DE6C63A7334 for <asrg@irtf.org>; Wed, 10 Feb 2010 04:41:58 -0800 (PST)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.135.133]:55403) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KXMM0Z-000ESV-1Y for asrg@irtf.org; Wed, 10 Feb 2010 12:43:47 +0000
Date: Wed, 10 Feb 2010 12:43:06 +0000
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <EBAE1512B9D3D5CB8F1239AD@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <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> <CDDB199D-DEF2-4D60-9AFE-F1651A50FE3B@blighty.com>
Originator-Info: login-token=Mulberry:01VVRbvb61ySKWwa8fwXrIyc4wu8x8F7h6yr8=; 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: Wed, 10 Feb 2010 12:42:00 -0000

--On 9 February 2010 09:49:47 -0800 Steve Atkins <steve@blighty.com> wrote:

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

I was using the term abuse report generically, to include any email that 
might be generated as a result of a user hitting a TiJ button. I'm hoping 
it's not going to use the word "spam".


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

It's not such a strange thing to enforce use of Message Submission Agents, 
is it? What I do is roughly equivalent to insisting on DKIM or SPF for my 
domain. I'm expecting that to become widespread, and I know that I'm not 
alone among institutional mail admins.

However, I'm definitely NOT going to exempt TiJ submissions. That would be 
tantamount to an invitation to spammers to poison my spam filters. If 
anything, I'm going to be more strict about the origins of those messages, 
not less.

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