Skip to main content

Last Call Review of draft-ietf-marf-authfailure-report-

Request Review of draft-ietf-marf-authfailure-report
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-01-13
Requested 2011-12-30
Authors Hilda L. Fontana
Draft last updated 2012-01-01
Completed reviews Genart Last Call review of -?? by Alexey Melnikov
Genart Last Call review of -?? by Alexey Melnikov
Assignment Reviewer Alexey Melnikov
State Completed
Review review-ietf-marf-authfailure-report-genart-lc-melnikov-2012-01-01
Completed 2012-01-01
I am the assigned Gen-ART reviewer for this draft. For background on 

Gen-ART, please see the FAQ at 


Please resolve these comments along with any other Last Call comments 

you may receive.

Document: draft-ietf-marf-authfailure-report-07

Reviewer: Alexey Melnikov

Review Date: 2012–01–01

IETF LC End Date: 2012-01-04

IESG Telechat date: 2012-01-19

Summary: This draft is almost ready for publication as a standard RFC, 

but it has some issues that need fixing/discussing.

Major issues:

I understand that this is a bit pedantic, but ID-nits reports the following:

  ** Downref: Normative reference to an Experimental RFC: RFC 4408 (ref.

and this was not called out during the IETF LC announcement.

This reference is truly Normative, so just making it Informative 

wouldn't work.

Minor issues:

1. Introduction

[ARF] defines a message format for sending reports of abuse in the
messaging infrastructure, with an eye towards automating both the
generation and consumption of those reports. There is now also a
desire to extend the ARF format to include reporting of messages that
fail to authenticate using known authentication methods, as these are
sometimes evidence of abuse that can be detected and reported through
automated means. The same mechanism can be used to convey forensic
information about the specific reason the authentication method
failed. Thus, this memo presents such extensions to the Abuse
Reporting Format to allow for detailed reporting of message
authentication method failures.

Maybe that is just me, but when I read "message authentication" I don't 

really have a clue what you are talking about. I needed to read the rest 

of the document in order to understand its scope.

2.2. Base 64

base64 is defined in [MIME].

The values that are base64 encodings may contain FWS for formatting
purposes as per the usual header field wrapping defined in [MAIL].
During decoding, any characters not in the base64 alphabet are
ignored so that such line wrapping does not harm the value.

This sentence can be read as allowing other invalid characters outside 

of FWS. I suggest you reword to make it clear that that is not the case.

token "FWS" is defined in [DKIM].

3.1. New ARF Feedback Type:

For privacy reasons, report generators might need to redact portions
of a reported message such as the end user whose complaint action
resulted in the report. See [I-D.IETF-MARF-REDACTION] for a

This reference is currently Normative and is a DownRef (as it wasn't 

called out explicitly during IETF LC). I don't think the reference needs 

to be Normative: making it Informative

will also get rid of the DownRef problem.

discussion of this.

3.2.2. Optional For All Reports

Delivery-Result: The final message disposition that was enacted by
the ADMD generating the report and MUST NOT appear more than once.

The first use of acronym ADMD needs expansion and, ideally, an 

informative reference to where the term is defined.

Possible values are:

In Section 4:

spf-dns = "SPF-DNS:" : { "txt" / "spf" } [FWS] ":" [FWS]
domain [FWS] ":" [FWS] quoted-string

I think this field is missing CRLF at the end.
Also, other fields listed in the same sections are using CFWS,
but this one doesn't. Should ABNF for this be aligned with other

Nits/editorial comments: None