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

Benoit Claise <> Wed, 25 April 2012 10:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B33BA21F8762; Wed, 25 Apr 2012 03:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_24=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vA51d5yvPn03; Wed, 25 Apr 2012 03:04:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9A15A21F875C; Wed, 25 Apr 2012 03:04:00 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id q3PA3uYg022964; Wed, 25 Apr 2012 12:03:56 +0200 (CEST)
Received: from [] ( []) by (8.13.8+Sun/8.13.8) with ESMTP id q3PA3u3E000210; Wed, 25 Apr 2012 12:03:56 +0200 (CEST)
Message-ID: <>
Date: Wed, 25 Apr 2012 12:03:56 +0200
From: Benoit Claise <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Murray S. Kucherawy" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 25 Apr 2012 12:59:06 -0700
Cc: me <>, "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [marf] Benoit Claise's Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Message Abuse Report Format working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Apr 2012 10:04:01 -0000

Hi Murray,
>> -----Original Message-----
>> From: Benoit Claise []
>> Sent: Monday, April 23, 2012 2:45 AM
>> To: The IESG
>> Cc:;
>> Subject: Benoit Claise's Discuss on draft-ietf-marf-as-14: (with
>> 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
>> criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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
>> 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.
Let me ask a very basic question to everybody, including the other IESG 
members: what is the goal of an Applicability Statement?
1. Explain how the technical specifications are used "in the wild", as 
you mentioned. So a deployment experience document
2. Or explain how the technical specifications should be used for the 
different use cases (generally specified in a requirement document)
When I read RFC 2026 section 3.2, I conclude for 2.

Even before re-reading RFC2026, my feeling was that an applicability 
statement could be the first document that someone new to a WG could 
read: explaining the different use cases, giving pointers to the 
technical specifications, and explaining how to apply/combine the 
specifications. Basically, a document that would help implementors to 
select which (part of the) spec. to implement depending on the use case, 
a document that would promote the technology. This is how we approached 
the Applicability Statement documents in the WGs I've been involved with.

Therefore, I'm in favor to mention how fraud, not-spam, virus should be 

Let me discuss this during the IETF telechat tomorrow, see what the 
others are thinking, and get back to you.
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> - 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.
Thanks. Can you please also a few sentences on how the documents match 
and differ.
You know, I see rfc6449, published a few months back, and I see this 
document draft-ietf-marf-as-14, which will be published approx. 6 months
And I'm wondering, as someone not involved in this WG...
- Why do we have two almost similar documents?
- Why RFC 6449 could not be a MARF document?
- Which one(s) should I read?
- Are they conflicting? If yes, I guess that draft-ietf-marf-as-14 take 
precedence. If no, is draft-ietf-marf-as-14 is superset of RFC 6449, and 
RFC 6449 should not be read any longer.
- etc...

I'm sure you had very good answers to all these questions, and I'm 
looking for some written explanation for new comers in this space.
>> - 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.
Thanks for your time and effort.

Regards, Benoit.
> -MSK