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

Steve Atkins <steve@blighty.com> Tue, 09 February 2010 18:14 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 84FC53A6849 for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 10:14:57 -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 oI-UqhgO4Dd0 for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 10:14:55 -0800 (PST)
Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id E5EEF28C143 for <asrg@irtf.org>; Tue, 9 Feb 2010 10:14:52 -0800 (PST)
Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id D9BAC80A9C for <asrg@irtf.org>; Tue, 9 Feb 2010 10:15:59 -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: <4B71A3D8.40401@tana.it>
Date: Tue, 09 Feb 2010 10:15:59 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5560296B-0CCB-4C6A-A1A7-4AC004BCEBD3@blighty.com>
References: <20100208150513.49394.qmail@simone.iecc.com> <0BF553ABE600903AE55F0E89@lewes.staff.uscs.susx.ac.uk> <4B718E2A.5070304@tana.it> <D0AC3DDE-3995-4EE9-9914-30E2831BAE22@blighty.com> <4B71A3D8.40401@tana.it>
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 18:14:57 -0000

On Feb 9, 2010, at 10:05 AM, 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.

None of that has anything to do with TiS buttons, though, which this thread is about. (Nor is it anything to do with feedback loops, which this thread is tangentially about).

> Besides that, I don't feel my model is much different than yours.

It is quite different (and I think wrong :)) which is why I'm stressing it.

We're not talking about abuse complaints in this thread, nor anything that would be sent to an existing role account.

That doesn't mean that a particular user might decide that sending either TiS notifications or FBL reports to a role address like sales@, postmaster@ or abuse@ is a good idea, but it's certainly not a requirement or even an expected behaviour[1].

> 
>> Rather there's one part of the chain that involves an end users MUA reporting a TiS button hit to their mail provider in a machine readable manner. That may well be done via SMTP, but if so it'll be to a dedicated email address (or set of email addresses) used solely for that function.
> 
> 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.
> 
>> The other part of the chain involves feedback loops, which are sent in response to the TiS hit. Pretty much all current ones are sent via SMTP, but not typically to an abuse@ address (it's certainly not best practice to do it that way). Again, they're intended for entirely automated handling and so are machine readable.
> 
> Yes, but I've used abuse@tana.it 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.
> 
>> Both parts of the service involve solicited, machine readable messages sent under a contractual agreement. That's very different from an abuse@ alias, which is dominated by unsolicited messages that are not intended to be machine readable.
> 
> Again, splitting the traffic may be convenient for heavy loads. However, I just whitelisted my abuse@ address from spam filtering. The moment I'll get a lot of ARF reports, it will be easy to add a recipient-filter that processes incoming messages only if they are in ARF format and leaves them in the current folder otherwise.

Yup, and that all works mostly OK (though you'll find some problems if you go the recipient-filter route). It's not the way I'd advise anyone to set things up as it won't scale well, but is quite workable for a small domain.

Cheers,
  Steve

[1] Sending FBL reports to sales@ does have a certain charm, though.