[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.
- [marf] Require body? Shmuel Metz (Seymour J.)
- Re: [marf] Require body? Murray S. Kucherawy
- Re: [marf] Require body? John Levine
- Re: [marf] Require body? Yakov Shafranovich
- Re: [marf] Require body? J.D. Falk
- Re: [marf] Require body? Shmuel Metz (Seymour J.)
- Re: [marf] Require body? Shmuel Metz (Seymour J.)
- Re: [marf] Require body? Shmuel Metz (Seymour J.)
- Re: [marf] Require body? Murray S. Kucherawy
- Re: [marf] Require body? Shmuel Metz (Seymour J.)
- [marf] Section 1.1 (was: Require body? Alessandro Vesely
- Re: [marf] Section 1.1 (was: Require body? Murray S. Kucherawy