Re: Proposed WG charter for "arf" (Abuse Report Format)

Alessandro Vesely <vesely@tana.it> Fri, 10 July 2009 13:44 UTC

Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368AC28C317 for <apps-discuss@core3.amsl.com>; Fri, 10 Jul 2009 06:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.761
X-Spam-Level:
X-Spam-Status: No, score=-2.761 tagged_above=-999 required=5 tests=[AWL=1.958, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
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 XL+dDN7w+3A5 for <apps-discuss@core3.amsl.com>; Fri, 10 Jul 2009 06:44:33 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id E4F6B28C321 for <discuss@ietf.org>; Fri, 10 Jul 2009 06:44:30 -0700 (PDT)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 10 Jul 2009 15:44:55 +0200 id 00000000005DC035.000000004A5745D7.00005028
Message-ID: <4A5745D7.4080606@tana.it>
Date: Fri, 10 Jul 2009 15:44:55 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "Murray S. Kucherawy" <msk@cloudmark.com>
Subject: Re: Proposed WG charter for "arf" (Abuse Report Format)
References: <BB012BD379D7B046ABE1472D8093C61C0112AA8C82@EXCH-C2.corp.cloudmark.com>
In-Reply-To: <BB012BD379D7B046ABE1472D8093C61C0112AA8C82@EXCH-C2.corp.cloudmark.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: discuss@ietf.org
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2009 13:44:34 -0000

Murray S. Kucherawy wrote:
> Furthermore, some extensions to the current proposal are 
> of interest to the community, such as the means for an operator to advertise 
> an email address to which abuse reports using ARF should be sent.

Apparently, that snippet considers "generic" reports. It is not 
explicit from the proposal if that email address is going to be 
specified in the same RFC that also standardizes the ARF. Since a 
(possibly different) email address is mentioned in your dkim-reporting 
draft, I understand a generic ARF email address is not what you aim 
for. In facts, there are two obvious arguments against it:

1) When feedback reports are processed by software, it may be 
convenient to have different addresses for different types of report.

2) The primary target for "generic" abuse reports (fraud, spam, virus, 
etcetera) would be the abuse desk of the organization accountable for 
originating the message. A document specifying where the target 
address can be found should also say how to identify such accountable 
originator, which is not a marginal task for a document --or a WG-- 
dedicated to a format specification.

OTOH, there are various possible synergies. For example, some of the 
r/rs/ri/ro/rs tags that describe feedback characteristics could be 
factored out in the ARF document, so as to avoid having to repeat them 
every time. SPF's softfail result might be a good candidate for 
collecting reports about SPF checks. DKIM's key reporting policy might 
require SPF "pass" to avoid collecting reports about extraneous 
transmitters trying to forge signatures. My vhlo draft defines the 
accountable originator mentioned in (2) above. Giving room to these 
synergies may expand the WG goals beyond reporting issues, and add one 
or two "issue/achieve/submit" triplets to its milestones. Would that 
be good or bad?