Re: [Asrg] RFC5451 Re: who gets the report, was We really don't need

"Murray S. Kucherawy" <msk@cloudmark.com> Mon, 08 February 2010 20:47 UTC

Return-Path: <msk@cloudmark.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 F169A3A727B for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 12:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level:
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599]
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 LWBNIeJM651q for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 12:47:35 -0800 (PST)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 458B23A7279 for <asrg@irtf.org>; Mon, 8 Feb 2010 12:47:35 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 8 Feb 2010 12:48:38 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Date: Mon, 8 Feb 2010 12:48:38 -0800
Thread-Topic: [Asrg] RFC5451 Re: who gets the report, was We really don't need
Thread-Index: Acqo+3LphjpSDRoYSAiTu1KP2+/MhgABFFQw
Message-ID: <BB012BD379D7B046ABE1472D8093C61C01C3C452F5@EXCH-C2.corp.cloudmark.com>
References: <20100208153359.56374.qmail@simone.iecc.com> <20100208164237.389722425C@panix5.panix.com> <4B704FFC.8040306@tana.it> <4B7059C9.2060102@nortel.com> <BB012BD379D7B046ABE1472D8093C61C01C3C452A4@EXCH-C2.corp.cloudmark.com> <4B7070AF.2050304@nortel.com>
In-Reply-To: <4B7070AF.2050304@nortel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Asrg] RFC5451 Re: who gets the report, was We really don't need
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: Mon, 08 Feb 2010 20:47:36 -0000

> -----Original Message-----
> From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of
> Chris Lewis
> Sent: Monday, February 08, 2010 12:15 PM
> To: Anti-Spam Research Group - IRTF
> Subject: Re: [Asrg] RFC5451 Re: who gets the report, was We really
> don't need
> 
> >> Could we not do this by extending 5451 semantics to have a "where to
> >> complain to" cause?
> >
> > That might work, if there's a reliable way to get that information
> > and relay it to MUAs.
> 
> It's a header in the email,

Which one?

> > Are you talking about an internal destination for spam reports (e.g.
> > your IT group), or an external one (e.g. abuse@domain)?
> 
> Either.  If you have an AR header you trust, there's no reason to
> refuse
> it giving you an external destination.

Where would you get the external destination to be reported to MUAs?

> Question is, how do we tell
> it's
> trusted, or do we care (especially with a site that's not 5451 aware)?
> 
> If we pitch it towards RFC5451-aware sites, and they pre-strip all
> non-locally originated AR headers (as permitted by RFC5451), there's no
> issue.  Are the sites that won't be a big enough concern?  Dunno.

I think you've answered it; an RFC5451-aware site would include that field only if it's convinced the value it's thus reporting is correct, having gotten it from some new parameter in a DKIM signature or something like that.  Otherwise it would report "abuse@(self-domain)", or nothing at all.