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/
- Re: [Asrg] Spam button scenarios Steve Atkins
- [Asrg] Spam button scenarios John R. Levine
- Re: [Asrg] Spam button scenarios Daniel Feenberg
- Re: [Asrg] Spam button scenarios Ian Eiloart
- Re: [Asrg] Spam button scenarios Andreas Saurwein Franci Gonçalves
- Re: [Asrg] Spam button scenarios John Levine
- Re: [Asrg] Spam button scenarios Ian Eiloart
- Re: [Asrg] Spam button scenarios Alessandro Vesely
- Re: [Asrg] Spam button scenarios Ian Eiloart
- Re: [Asrg] Spam button scenarios John Levine
- Re: [Asrg] Spam button scenarios Derek Diget
- Re: [Asrg] Spam button scenarios Martijn Grooten
- Re: [Asrg] Spam button scenarios der Mouse
- Re: [Asrg] Spam button scenarios Bill Weinman
- Re: [Asrg] Spam button scenarios Chris Lewis
- Re: [Asrg] Spam button scenarios Seth
- Re: [Asrg] Spam button scenarios Steve Atkins
- Re: [Asrg] Spam button scenarios Martijn Grooten
- Re: [Asrg] Spam button scenarios John Levine
- Re: [Asrg] Spam button scenarios Ian Eiloart
- Re: [Asrg] Spam button scenarios Ian Eiloart
- [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Steve Atkins
- Re: [Asrg] ARF traffic, was Spam button scenarios Ian Eiloart
- Re: [Asrg] ARF traffic, was Spam button scenarios Steve Atkins
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Steve Atkins
- Re: [Asrg] ARF traffic, was Spam button scenarios Chris Lewis
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Steve Atkins
- Re: [Asrg] ARF traffic, was Spam button scenarios Chris Lewis
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Alessandro Vesely
- Re: [Asrg] ARF traffic, was Spam button scenarios Ian Eiloart
- Re: [Asrg] ARF traffic, was Spam button scenarios Ian Eiloart