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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
