Skip to main content

An Extensible Format for Email Feedback Reports
RFC 5965

Revision differences

Document history

Date Rev. By Action
2020-01-21
06 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
06 (System) Notify list changed from marf-chairs@ietf.org, draft-ietf-marf-base@ietf.org, ietf@cybernothing.org to ietf@cybernothing.org
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2010-08-31
06 Cindy Morgan State changed to RFC Published from RFC Ed Queue by Cindy Morgan
2010-08-31
06 Cindy Morgan [Note]: changed to 'RFC 5965' by Cindy Morgan
2010-08-30
06 (System) RFC published
2010-05-27
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-05-27
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-05-27
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-05-27
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-05-24
06 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-05-24
06 (System) IANA Action state changed to In Progress
2010-05-24
06 Amy Vezza IESG state changed to Approved-announcement sent
2010-05-24
06 Amy Vezza IESG has approved the document
2010-05-24
06 Amy Vezza Closed "Approve" ballot
2010-05-21
06 (System) New version available: draft-ietf-marf-base-06.txt
2010-05-21
06 (System) Removed from agenda for telechat - 2010-05-20
2010-05-20
06 Cindy Morgan State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Cindy Morgan
2010-05-20
06 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2010-05-20
06 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2010-05-20
06 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2010-05-20
06 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-05-20
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-05-20
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-05-20
06 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2010-05-19
06 David Harrington [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss by David Harrington
2010-05-19
06 David Harrington
[Ballot comment]
I support Tim's DISCUSS.

in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are …
[Ballot comment]
I support Tim's DISCUSS.

in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are we continuing its support here?
what happens if a Recived-Date and an Arrival-Date bith exist, and are different?
2010-05-19
06 David Harrington [Ballot discuss]
2010-05-19
06 Russ Housley
[Ballot comment]
The introduction says:
  >
  > This memo seeks to define a standard extensible format by creating
  > the "message/feedback-report" [MIME] …
[Ballot comment]
The introduction says:
  >
  > This memo seeks to define a standard extensible format by creating
  > the "message/feedback-report" [MIME] type for these reports.
  >
  Two points.  First, this specification defines the message/feedback-
  report.  Please drop "seeks to".  Second, the new MIME type is one
  part in the overall email feedback report, but talking about this one
  piece before talking about multipart/report in the introduction lead
  me to a different expectation.  That incorrect expectation is
  corrected in the subsequent paragraph.  A top-down ordering here
  would have helped me.

  Section 3.1 says:
  >
  > o  "Version" indicates the version of specification that the report
  >    generator is using to generate the report.  The version number in
  >    this specification is set to "0.1".  [NOTE TO RFC EDITOR: This
  >    should be changed to "1" at time of publication.]
  >
  Note that "0.1" is not valid under the Version ABNF definition.
2010-05-19
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2010-05-19
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2010-05-19
06 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-05-19
06 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2010-05-19
06 Alexey Melnikov State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Alexey Melnikov
2010-05-19
06 Alexey Melnikov [Note]: 'J.D. Falk <ietf@cybernothing.org> is the document shepherd.<br>' added by Alexey Melnikov
2010-05-18
06 David Harrington
[Ballot comment]
I support Tim's DISCUSS.

in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are …
[Ballot comment]
I support Tim's DISCUSS.

in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are we continuing its support here?
what happens if a Recived-Date and an Arrival-Date bith exist, and are different?
2010-05-18
06 David Harrington
[Ballot discuss]
in section 4, there is no requirement as to envelope sender. How will this impact interoperability? Th ewhol epurpose of this document is …
[Ballot discuss]
in section 4, there is no requirement as to envelope sender. How will this impact interoperability? Th ewhol epurpose of this document is eliminate so receivers won't need to write custom software for each report sender's variations. Doesn't this lack of standard for envelope sender guarantee receivers will need to write custom software for each envelope sender choice?
2010-05-18
06 David Harrington [Ballot Position Update] Position for David Harrington has been changed to Discuss from No Objection by David Harrington
2010-05-18
06 David Harrington
[Ballot comment]
I support Tim's DISCUSS.

in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are …
[Ballot comment]
I support Tim's DISCUSS.

in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are we continuing its support here?
what happens if a Recived-Date and an Arrival-Date bith exist, and are different?
2010-05-18
06 David Harrington [Ballot Position Update] New position, No Objection, has been recorded by David Harrington
2010-05-18
06 Peter Saint-Andre [Ballot comment]
Cleared.
2010-05-18
06 Peter Saint-Andre [Ballot discuss]
2010-05-18
06 Peter Saint-Andre [Ballot Position Update] Position for Peter Saint-Andre has been changed to Yes from Discuss by Peter Saint-Andre
2010-05-18
05 (System) New version available: draft-ietf-marf-base-05.txt
2010-05-18
06 Peter Saint-Andre [Ballot comment]
I support Tim's DISCUSS positions.
2010-05-18
06 Peter Saint-Andre
[Ballot discuss]
1. The security considerations probably need to note that the "User-Agent" field is merely asserted and cannot be relied upon (e.g., it is …
[Ballot discuss]
1. The security considerations probably need to note that the "User-Agent" field is merely asserted and cannot be relied upon (e.g., it is often forged by HTTP user agents and presumably MUAs too).

2. Do we really want to be encouraging "x-" for header names? Is there any harm in deprecating this usage here and allowing any header names?

3. No information is provided regarding versioning of the protocol itself. You might consider text like this:

###

The numbering scheme for MARF versions is "<major>.<minor>". The major and minor numbers MUST be treated as separate integers and each number MAY be incremented higher than a single digit. Thus, "MARF 2.4" would be a lower version than "MARF 2.13", which in turn would be lower than "MARF 12.3". Leading zeros (e.g., "MARF 6.01") MUST NOT be generated and MUST be ignored if found.

The major version number will be incremented only if the data formats and protocol actions have changed so dramatically that an older version entity would not be able to interoperate with a newer version entity if it simply ignored the data it did not understand and took the actions defined in the older specification.  As an example, the major version number needs to be incremented if new required fields are defined.

The minor version number will be incremented only if significant, non-required capabilities have been added to the core protocol (e.g., new optional fields or feedback report types). The minor version number MUST be ignored by an entity with a smaller minor version number, but MAY be used for informational purposes by the entity with the larger minor version number.

###
2010-05-18
06 Peter Saint-Andre [Ballot Position Update] New position, Discuss, has been recorded by Peter Saint-Andre
2010-05-18
06 Sean Turner [Ballot comment]
I support Tim's DISCUSS positions.
2010-05-18
06 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner
2010-05-18
06 Tim Polk
[Ballot comment]
It would be helpful (IMHO, anyway) if section 3 included a forward pointer to section 5 (extensibility).    The content of section 3 …
[Ballot comment]
It would be helpful (IMHO, anyway) if section 3 included a forward pointer to section 5 (extensibility).    The content of section 3 does not indicate that a marf processor should expect
to see unknown fields.
2010-05-18
06 Tim Polk
[Ballot discuss]
This discuss has three parts:  The first issue is actionable, the second and third are intended as
a discuss-discuss.

(1) This document is …
[Ballot discuss]
This discuss has three parts:  The first issue is actionable, the second and third are intended as
a discuss-discuss.

(1) This document is conspicuously silent regarding S/MIME.  Considering the importance of
vetting the source of an abuse report, it would seem that S/MIME is ideal.  The mechanisms
that are explicitly highlighted are much weaker than S/MIME. S/MIME would mitigate some of
the risks identified currently in section 7 - they derive in part from the weak authentication
properties associated with the other mechanisms.  Issues regarding the usability of S/MIME
are generally irrelevant for MARF, since the set of trusted sources is fairly small and many
reports are generated automatically.

(2) This is the discuss-discuss.  To be clear, I am not asking for any action regarding this
issue at this time.  After the telechat, I will revise this issue to make it actionable or I will
delete this issue.

The MARF message report has three components: a human readable report; a machine
readable report; and the offending message.  I am worried about instances where the
human readable and machine readable reports are inconsistent.  If an administrator initiates
processes based on the human readable report, but the process is directed by the machine
readable report, and attacker can exploit this to cause harm.  I would like to know if the
wg considered such a scenario, and whether any mitigating controls were identified.

Personally, I would like to be sure the source of a message is strongly authenticated
(e.g., verify the S/MIME signature from a trusted source) before initiating such a process
based on the human readable report.

(3) This is the discuss-discuss.  To be clear, I am not asking for any action regarding this
issue at this time.  After the telechat, I will revise this sisue to make it actionable or I will
delete this issue.

Should the ABNF include a production that allows for encountering unknown fileds (i.e.,
optional fields defined in later specifications)?  [See related comment below]
2010-05-18
06 Tim Polk
[Ballot comment]
It would be helpful (IMHO, anyway) if section 3 included a forward pointer to section 5 (extensibility).    The content of section 3 …
[Ballot comment]
It would be helpful (IMHO, anyway) if section 3 included a forward pointer to section 5 (extensibility).    The content of section 3 does not indicate that a marf processor should expect
to see unknown fields.
2010-05-18
06 Tim Polk
[Ballot discuss]
This discuss has two parts:  The first issue is actionable, the second is intended as a discuss-discuss.

(1) This document is conspicuously silent …
[Ballot discuss]
This discuss has two parts:  The first issue is actionable, the second is intended as a discuss-discuss.

(1) This document is conspicuously silent regarding S/MIME.  Considering the importance of
vetting the source of an abuse report, it would seem that S/MIME is ideal.  The mechanisms
that are explicitly highlighted are much weaker than S/MIME. S/MIME would mitigate some of
the risks identified currently in section 7 - they derive in part from the weak authentication
properties associated with the other mechanisms.  Issues regarding the usability of S/MIME
are generally irrelevant for MARF, since the set of trusted sources is fairly small and many
reports are generated automatically.

(2) This is the discuss-discuss.  To be clear, I am not asking for any action regarding this
issue at this time.  After the telechat, I will revise this issue to make it actionable or I will
delete this issue.

The MARF message report has three components: a human readable report; a machine
readable report; and the offending message.  I am worried about instances where the
human readable and machine readable reports are inconsistent.  If an administrator initiates
processes based on the human readable report, but the process is directed by the machine
readable report, and attacker can exploit this to cause harm.  I would like to know if the
wg considered such a scenario, and whether any mitigating controls were identified.

Personally, I would like to be sure the source of a message is strongly authenticated
(e.g., verify the S/MIME signature from a trusted source) before initiating such a process
based on the human readable report.

(3) This is the discuss-discuss.  To be clear, I am not asking for any action regarding this
issue at this time.  After the telechat, I will revise this sisue to make it actionable or I will
delete this issue.

Should the ABNF include a production that allows for encountering unknown fileds (i.e.,
optional fields defined in later specifications)?  [See related comment below]
2010-05-18
06 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2010-05-14
06 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-05-10
06 Amanda Baber
IANA comments:

Upon approval of this document, IANA will perform the following actions:

ACTION 1:

make the following assignment in the "Message Media Types" registry …
IANA comments:

Upon approval of this document, IANA will perform the following actions:

ACTION 1:

make the following assignment in the "Message Media Types" registry at
http://www.iana.org/assignments/media-types/message/

id Reference
--------------- ------------
feedback-report [RFCmarf-base-04]


ACTION 2:

Create the following registry at http://www.iana.org/assignments/TBD

Registry Name: Feedback Report Header Fields
Registration Procedures: Specification Required

The registry will have the following columns:
- Field Name
- Description
- Multiple Appearances: No
- Related "Feedback-Type"
- Status
- Reference

The content will be taken from section 6.2.


ACTION 3:

Create the following registry at http://www.iana.org/assignments/TBD

Registry Name: Feedback Report Type Values
Registration Procedure: Specification Required

The registry will have the following columns:
- Feedback Type Name
- Description
- Status
- Reference

The content will be taken from section 6.3.
2010-05-07
06 Alexey Melnikov [Note]: 'J.D. Falk <ietf@cybernothing.org> is the document shepherd.<br>This document needs a quick update after IETF LC.' added by Alexey Melnikov
2010-05-07
06 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2010-05-07
06 Alexey Melnikov Ballot has been issued by Alexey Melnikov
2010-05-07
06 Alexey Melnikov Created "Approve" ballot
2010-05-07
06 Alexey Melnikov Placed on agenda for telechat - 2010-05-20 by Alexey Melnikov
2010-05-03
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Dave Cridland
2010-05-03
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Dave Cridland
2010-04-30
06 Cindy Morgan Last call sent
2010-04-30
06 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2010-04-30
06 Alexey Melnikov Last Call was requested by Alexey Melnikov
2010-04-30
06 Alexey Melnikov State Changes to Last Call Requested from AD Evaluation::AD Followup by Alexey Melnikov
2010-04-30
06 (System) Ballot writeup text was added
2010-04-30
06 (System) Last call text was added
2010-04-30
06 (System) Ballot approval text was added
2010-04-30
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-04-30
04 (System) New version available: draft-ietf-marf-base-04.txt
2010-04-24
06 Alexey Melnikov
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
  …
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

I, J.D. Falk, am acting as Document Shepherd.  Along with the WG Chairs, I have reviewed this version and believe it is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

This specification has been reviewed, refined, and implemented by dozens of generators and hundreds of consumers of the format.  Though some discussion occurred during the WGLC, the answers were either found in the document or previously recognized as being out of scope.  The Document Shepherd has no concerns about the level of review.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

Quite a few of the foremost experts in email protocols and abuse reporting practices, including many who were not previously IETF participants, were involved in the discussions leading to this draft.  I do not believe that additional review is warranted.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

I have no such concerns.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

When meeting during IETF 77 and on the WG mailing list, consensus around the points in this document has been clear and solid.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No conflict.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

I believe that all of these requirements have been satisfied.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The Normative and Informative reference sections are complete, and there are no downward Normative references.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The IANA registries are clear and actionable.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No errors were found by http://tools.ietf.org/tools/bap/abnf.cgi .

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.

Technical Summary

  This document defines an extensible format and MIME type that may be
  used by network operators to report feedback about received email to
  other parties.  This format is intended as a machine-readable
  replacement for various existing report formats currently used in
  Internet email.

Working Group Summary

  The majority of development of this specification took place outside
  of the IETF between 2005 and 2007, resulting in a de facto standard
  with many large-scale implementations.  The recent work within the
  MARF Working Group has resulted in a more precise document, and has
  revealed some items for discussion in future documents.

Document Quality

  The Working Group is aware of more than a dozen generators of reports
  which follow this specification, and hundreds of consumers of those
  reports.  These include most of the largest mailbox providers and email
  service providers, and many smaller operators.  Many of the WG members
  are also implementors, and many additional implementers who are not
  currently WG  participants have reviewed this document and/or earlier
  revisions.
2010-04-24
06 Alexey Melnikov
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
  …
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

I, J.D. Falk, am acting as Document Shepherd.  Along with the WG Chairs, I have reviewed this version and believe it is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

This specification has been reviewed, refined, and implemented by dozens of generators and hundreds of consumers of the format.  Though some discussion occurred during the WGLC, the answers were either found in the document or previously recognized as being out of scope.  The Document Shepherd has no concerns about the level of review.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

Quite a few of the foremost experts in email protocols and abuse reporting practices, including many who were not previously IETF participants, were involved in the discussions leading to this draft.  I do not believe that additional review is warranted.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

I have no such concerns.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

When meeting during IETF 77 and on the WG mailing list, consensus around the points in this document has been clear and solid.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No conflict.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

I believe that all of these requirements have been satisfied.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The Normative and Informative reference sections are complete, and there are no downward Normative references.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The IANA registries are clear and actionable.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No errors were found by http://tools.ietf.org/tools/bap/abnf.cgi .

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.

Technical Summary

  This document defines an extensible format and MIME type that may be
  used by network operators to report feedback about received email to
  other parties.  This format is intended as a machine-readable
  replacement for various existing report formats currently used in
  Internet email.

Working Group Summary

  The majority of development of this specification took place outside
  of the IETF between 2005 and 2007, resulting in a de facto standard
  with many large-scale implementations.  The recent work within the
  MARF Working Group has resulted in a more precise document, and has
  revealed some items for discussion in future documents.

Document Quality

  The Working Group is aware of more than a dozen generators of reports
  which follow this specification, and hundreds of consumers of those
  reports.  These include most of the largest mailbox providers and email
  service providers, and many smaller operators.  Many of the WG members
  are also implementors, and many additional implementers who are not
  currently WG  participants have reviewed this document and/or earlier
  revisions.
2010-04-24
06 Alexey Melnikov State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Alexey Melnikov
2010-04-24
06 Alexey Melnikov State Change Notice email list have been change to marf-chairs@tools.ietf.org, draft-ietf-marf-base@tools.ietf.org, ietf@cybernothing.org from marf-chairs@tools.ietf.org, draft-ietf-marf-base@tools.ietf.org
2010-04-24
06 Alexey Melnikov [Note]: 'J.D. Falk <ietf@cybernothing.org> is the document shepherd' added by Alexey Melnikov
2010-04-24
06 Alexey Melnikov State Changes to AD Evaluation from Publication Requested by Alexey Melnikov
2010-04-21
06 Alexey Melnikov Earlier history may be found in the Comment Log for <a href="/doc/draft-shafranovich-feedback-report/">draft-shafranovich-feedback-report</a>.
2010-04-21
03 (System) New version available: draft-ietf-marf-base-03.txt
2010-04-06
02 (System) New version available: draft-ietf-marf-base-02.txt
2010-02-23
01 (System) New version available: draft-ietf-marf-base-01.txt
2010-01-27
06 (System) Earlier history may be found in the Comment Log for <a href="/doc/draft-shafranovich-feedback-report/">draft-shafranovich-feedback-report</a>.
2010-01-27
06 (System) Draft Added by the IESG Secretary in state 0.  by system
2010-01-26
00 (System) New version available: draft-ietf-marf-base-00.txt