Subject: Protocol Action: 'Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)' to Proposed Standard (draft-ietf-marf-as-16.txt)

From: The IESG <[email-masked]>
Date: Mon, 30 Apr 2012 11:03:48 -0700

The IESG has approved the following document:
- 'Creation and Use of Email Feedback Reports: An Applicability Statement
   for the Abuse Reporting Format (ARF)'
  (draft-ietf-marf-as-16.txt) as a Proposed Standard

This document is the product of the Messaging Abuse Reporting Format
Working Group.

The IESG contact persons are Pete Resnick and Barry Leiba.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-marf-as/

Technical Summary 

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. 

Working Group Summary 

The primary contention point in the development of this document involved 
what and how much to include, striking a balance between an Applicability 
Statement and an "implementation cookbook". Because we have limited 
recent experience with Applicability Statements, the participants were not 
sure what belongs in them, and what constitutes "too much detail" that's 
best left for other forms of documentation. 

In the end, the working group produced a version that most of the 
participants could be happy with, and the document as presented has the 
broad support of the MARF working group. 

Document Quality 

This document reflects the current MARF implementations in the field, 
of which there are many. That said, we do expect that it might be 
modified over time, as the MARF base specification itself matures along 
the Standards Track. 

Personnel 

Barry Leiba is the document shepherd; Pete Resnick is the 
responsible AD. 

RFC Editor Notes

Please make the following changes to -16:

OLD (Section 1):

   Further introduction to this topic may be found in [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.

NEW:

   Further introduction to this topic may be found in [RFC6449], which
   has more information about the general topic of abuse reporting.  Many
   of the specific ARF guidelines in this document were taken from the
   principles presented in [RFC6449].

OLD (Section 5.1):

   2.  Message authentication is generally a good idea, but it is
       especially important to encourage credibility of and thus
       response to unsolicited reports.  Therefore, as with any other
       message, Feedback Providers sending unsolicited reports SHOULD
       send reports that they believe will pass Sender Policy Framework
       ([RFC4408]) and/or DomainKeys Identified Mail ([RFC6376]) checks.

NEW:

   2.  Message authentication is generally a good idea, but it is
       especially important to encourage credibility of and thus
       response to unsolicited reports.  Therefore, as with any other
       message, Feedback Providers sending unsolicited reports SHOULD
       send reports that they expect will pass Sender Policy Framework
       ([RFC4408]) and/or DomainKeys Identified Mail ([RFC6376]) checks.