[marf] Section 1.1 (was: Require body?

Alessandro Vesely <vesely@tana.it> Fri, 16 April 2010 10:53 UTC

Return-Path: <vesely@tana.it>
X-Original-To: marf@core3.amsl.com
Delivered-To: marf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3D128C107 for <marf@core3.amsl.com>; Fri, 16 Apr 2010 03:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.066
X-Spam-Level:
X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_50=0.001, 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 LAVrqQqcpMQB for <marf@core3.amsl.com>; Fri, 16 Apr 2010 03:53:37 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 37E443A6932 for <marf@ietf.org>; Fri, 16 Apr 2010 03:53:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1271415208; bh=OEAnuqA8TIl4aQ1DU7shIm5tLrP2BVJAJomJ4VRxMr0=; l=1850; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ZdX84y/4QIezKLl56oj3W92YlLZMvCId4gme20XoUcyPIE+cDidgBrhbuh1V9v3PM Ascym2CtbBGrlaNAKFWyMY8hZynImk2nvcRgLWMgID6m7bUTKGKsPgGAAHzYQwcnLF ULtApb+jp8rtkchafErZB5HuEA7jZg8I+ROx07Vc=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 16 Apr 2010 12:53:28 +0200 id 00000000005DC035.000000004BC841A8.000069F7
Message-ID: <4BC841A7.1060704@tana.it>
Date: Fri, 16 Apr 2010 12:53:27 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: marf@ietf.org
References: <BB012BD379D7B046ABE1472D8093C61C01CFEA49AC@EXCH-C2.corp.cloudmark.com> <20100415100620.9A85AF5808A@smtp.patriot.net> <BB012BD379D7B046ABE1472D8093C61C01CFEA4D0E@EXCH-C2.corp.cloudmark.com>
In-Reply-To: <BB012BD379D7B046ABE1472D8093C61C01CFEA4D0E@EXCH-C2.corp.cloudmark.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [marf] Section 1.1 (was: Require body?
X-BeenThere: marf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Message Abuse Report Format working group discussion list <marf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/marf>, <mailto:marf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/marf>
List-Post: <mailto:marf@ietf.org>
List-Help: <mailto:marf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/marf>, <mailto:marf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 10:53:38 -0000

On 15/Apr/10 19:56, Murray S. Kucherawy wrote:
> Actually I don't like the current format of 1.1, now that you mention it.
>
> How's this?
>
>                          <t>  The reports defined in this document are intended
>                              to inform operators about:

Since the previous section is fairly generic, IMHO this should be more 
specific, e.g. "mail operators", or "mailbox providers and email 
service providers".

>
>                              <list style="symbols">
>                                  <t>  email abuse originating from their
>                                      networks;</t>
>
>                                  <t>  potential issues with the perceived
>                                      quality of outbound mail, such as email
>                                      service providers sending mail in a format
>                                      that causes automated abuse detection
>                                      systems to consider it suspect.</t>

IMHO this may be less specific, so as to broaden the class of 
exemplified uses; e.g. "such as email service providers sending mail 
that causes problems with abuse detection systems."

>                              </list>  </t>


Do you mean to drop the last paragraph ("Please note [...] and SHOULD 
NOT be used for other reports.")?

It is still unclear whether this section is meant to also cover future 
extensions. I don't think we want to limit possible uses of ARF. 
However, we may inform about alternative formats for reporting email 
messages: rfc3462 for end users, and the upcoming 
draft-cain-post-inch-phishingextns for network providers. Adding such 
information may identify by exclusion our niche of treatable abuses 
that are neither delivery errors nor manifest attacks.