On Mon, Jan 5, 2015 at 1:43 PM, Jim Fenton <fen...@bluepopcorn.net> wrote:
> 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. > Unfortunately, -10 is now current per feedback received last week. I had expected that to be the last one, especially this close to the telechat. However: 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." > Fixed, since it's minor. > 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. > Actually I think this is more major than a nit, even though it's really the result of an unfortunate little XML error. This is the main reason I'm preparing a -11 now (sigh). 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. > I'm inclined to punt this to the working group to sort out if it decides this is a problem. It's too late in this document's lifecycle to be making possibly non-trivial syntax or semantic changes such as this. 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. > Same answer here. This is an ISE document recording current practice; it's OK for us to have gotten technical details wrong, and up to the working group to decide if and how to fix them. > 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" > What's the normative difference between "are to be taken" and "MUST be taken"? In either case, if you don't take these steps, you're non-compliant. Either way, the risk is already described. > 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. > Removed; redundant it is. > 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..." > This is intentionally not normative, and thus also something to be decided by the WG at this stage. > 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. > I believe Pete, and probably others, would assert that the present language is normative. RFC2119 terms are not the only ways we have to say normative things. 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. > Not only is that another late-stage technical issue to punt to the working group, but I also claim that's a layering violation. SPF simply reports a pass/fail/temperror/etc. It's not the purview of DMARC to ask what kind of "pass" it was any more than it is the purview of DMARC to ask which header fields or how much body was covered by an aligned DKIM signature. Neither SPF nor DKIM report those things. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
