Re: [marf] Benoit Claise's Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)

"Murray S. Kucherawy" <msk@cloudmark.com> Tue, 24 April 2012 23:33 UTC

Return-Path: <msk@cloudmark.com>
X-Original-To: marf@ietfa.amsl.com
Delivered-To: marf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD5F11E809A for <marf@ietfa.amsl.com>; Tue, 24 Apr 2012 16:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level:
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVgSKESuO+kJ for <marf@ietfa.amsl.com>; Tue, 24 Apr 2012 16:33:56 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 645A311E8089 for <marf@ietf.org>; Tue, 24 Apr 2012 16:33:56 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1za71j0010ZaKgw01za7l8; Tue, 24 Apr 2012 16:34:16 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=vGmJt43tM7QA:10 a=zutiEJmiVI4A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=DoBm3Fp9mfi8Wj41-yQA:9 a=UNNc2HJscSv4ZvxtjA0A:7 a=QEXdDO2ut3YA:10 a=JfD0Fch1gWkA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 16:33:46 -0700
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: Benoit Claise <bclaise@cisco.com>, The IESG <iesg@ietf.org>
Thread-Topic: Benoit Claise's Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)
Thread-Index: AQHNITXMIbyZo9yVYUqgbSkbCNchdJaqoG6Q
Date: Tue, 24 Apr 2012 23:33:45 +0000
Message-ID: <9452079D1A51524AA5749AD23E00392810193D@exch-mbx901.corp.cloudmark.com>
References: <20120423094450.10355.95358.idtracker@ietfa.amsl.com>
In-Reply-To: <20120423094450.10355.95358.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.20.2.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335310457; bh=vb3Mg9v0zysZW7uYYjXzd4gVf1r50h6z8em5hiw3qJc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=abtssiqqgtvLRS1lq1VhmWNm3oMWco03FfWfzu8QoZYRwrs8ZFSx4T/biQJXcRJv7 iIGLf0nZCHZxyIFTrKEfeSQVxSPkZfRuAKM34+fQQYXvgo1b17VtHYihMcKxtgVZWH 50jRnl+gWRqcbBEsTWEeQFXGEX18gSs07VTo+cUc=
Cc: "draft-ietf-marf-as@tools.ietf.org" <draft-ietf-marf-as@tools.ietf.org>, "marf-chairs@tools.ietf.org" <marf-chairs@tools.ietf.org>, "marf@ietf.org" <marf@ietf.org>
Subject: Re: [marf] Benoit Claise's Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)
X-BeenThere: marf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Message Abuse Report Format working group discussion list <marf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 24 Apr 2012 23:33:57 -0000

> -----Original Message-----
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Monday, April 23, 2012 2:45 AM
> To: The IESG
> Cc: marf-chairs@tools.ietf.org; draft-ietf-marf-as@tools.ietf.org
> Subject: Benoit Claise's Discuss on draft-ietf-marf-as-14: (with
> DISCUSS and COMMENT)
> 
> Benoit Claise has entered the following ballot position for
> draft-ietf-marf-as-14: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> DISCUSS-DISCUSS
> 
> Abstract
> 
>    RFC 5965 defines an extensible, machine-readable format intended for
>    mail operators to report feedback about received email to other
>    parties.  This Applicability Statement describes common methods for
>    utilizing this format for reporting both abuse and authentication
>    failure events.  Mailbox Providers of any size, mail sending
>    entities, and end users can use these methods as a basis to create
>    procedures that best suit them.  Some related optional mechanisms are
>    also discussed.
> 
> Before reviewing this draft, I browsed through the 4 RFCs at
> http://datatracker.ietf.org/wg/marf/
> Question: is this intentional that the abstract and the draft only
> mention the "abuse" and "auth-failure" Feedback Type Name, and not the
> others ones?
> 	fraud 		[RFC5965]
> 	not-spam	[RFC6430]
> 	virus		[RFC5965]
> 
> Not a single reference to fraud, not-spam, virus, and [RFC6430] I'm
> surprised not to see the full ARF capacities mentioned in a document
> titled "An Applicability Statement for the Abuse Reporting Format
> (ARF)", and would like to understand.

We've simply not seen enough use of these in the wild to be able to comment on their proper or recommended use in this AS.  The original document that became RFC5965 actually listed a large number of other report types that were at one time thought to be useful, but were removed prior to publication because nobody had used them.  "fraud" and "virus" did see rare use but remain edge cases, so they remained in the list registered by RFC5965.

We can (and probably should) mention this in the Introduction.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> - I see a lot of sentences such as "... discussed in Section X of
> [RFC6449]."
> And the only sentence in the introduction related to that RFC is:
> "Further introduction to this topic may be found in [RFC6449]."
> Some sentences explaining what this informational RFC is about would be
> very welcome.

I propose this as the last paragraph to the Introduction:

Further introduction to this topic may be found in <xref target="RFC6449"/>, which is effectively an Applicability Statement written outside of the IETF and thus never achieved IETF consensus.  Much of the content for that document was input to this one.

> - please expand SPF

OK, and will do for DKIM as well.

> - Section 5.2
> "RFC5321.MailFrom" Doesn't read right to me in: "If a Feedback Provider
> applies SPF to arriving messages, a report SHOULD NOT be generated to
> the RFC5321.MailFrom domain"

It's a notation introduced in RFC5598, which is a normative reference here.

-MSK