[dmarc-ietf] Comments on dmarc-base-09

[Jim Fenton <[e-mail]>]

I went back over my -04 comments while looking at -09, and the great
majority have been resolved. There are still a few things that haven't
been adequately addressed, as far as I can tell, nor resolved on-list. 
I haven't thoroughly gone through the -09 draft, and don't think that
would yield much new at this point.

Here are the residual items. Apologies if I'm re-raising something that
has been discussed, but I forgot about. Section numbers have been
corrected for the -09 draft.

Section 3, definition of Report Receiver: "...reports about the messages
claiming to be from a third party." Comparing with the previous
sentence, the third party referred to here seems to be another operator
that is sending reports to the Report Receiver. Suggest substituting,
"...reports about messages relating to another operator."

Section 3.1/3.2, organization nit: It seems a little odd for the
Overview and Authentication Mechanisms to be subsections of the
Terminology and Definitions.

Section 5.3, definition of fo: parameter: I had reported that there
isn't any prohibition on specifying both 0 and 1, and I thought someone
said that was fixed but I can't find it. More generally, I struggle to
find any real utility for a colon-separated list of options here.

Section 5.3, definition of pct: parameter: "However, this MUST NOT be
applied to the DMARC-generated reports, all of which must be sent and
received unhindered." This is strong normative language, but there is no
procedure specified anywhere for how to identify a DMARC-generated
report in order to apply this requirement. Consider the possibility that
bad actors may try to craft messages to look like DMARC reports.

Section 6.1, paragraph 3: "...the following verification steps are to be
taken"  It looks like this was changed in response to my earlier
objection to a SHOULD here, but now we have language that isn't clear.
Suggest "...the following verification steps MUST be taken"

Section 6.3, paragraph 4, "The format for failure reports is defined in
[AFRF]."  This is redundant with the previous paragraph and can be deleted.

Section 6.2.1.1, "The filename is typically constructed..." Again, this
is fuzzy normative language; it sounds like it's trying to say, "The
filename MAY be constructed..."

Section 6.3.1: "Operators implementing this specification also
implement..."  This needs a normative term, SHOULD or MUST. Not sure
which one.  Again, I think the SHOULD requirement on the Subject header
field is likely to trick an implementer into depending on it, and you
can't unless it's a MUST. The information is included in the report anyway.

Not mentioned anywhere: Which SPF modes are considered to be a "pass"
for purposes of DMARC? Presumably +, presumably not -, but it should say
something about ? and ~ if it doesn't already.

-Jim