-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Kitterman wrote:
> On Tuesday, June 28, 2011 09:35:07 AM [email protected] wrote: > ... > > > Title : SPF Authentication Failure Reporting using the > > Abuse Report Format > > Author(s) : Scott Kitterman > > ... > > This is the first draft of the split out document. Please review and > let me know how it can be improved. Interesting. As you personally asked me to do, here's a thorough review. Shouldn't it say "Updates: 4408, 5965" at the top? Can a Standards Track document refer *normatively* to an Experimental document (RFC 4408)? (Nota bene, I'm all for this document, I'm merely posing the formal question.) In section 3, "Optional Reporting Address for SPF", in the "r=" definition, why is it a "SHOULD" in "an e-mail address to which a report SHOULD be sent"? Anyone following this document should be told they MUST send a report to that e-mail address (subject to the ri=/ro= specifications); anyone *not* following this document will do what they want anyway (with regard to this document). Perhaps it's better to word this as follows: "A local-part or addr-spec (...) specifying an e-mail address to which the domain owner expects reports to be sent when ..." In the same paragraph it says: "The format of this reply" — s/reply/report/. It says: "the domain whose policy was queried" — this might be ambiguous in the context of a possible future overarching policy standard, so s/policy/SPF record/ (the remainder of the sentence can then probably be removed). In the same paragraph the ABNF grammar is incorrect: the SPF grammar does *not* allow WSP around the "=" character. The same problem exists in the later grammar rules in this document. Generally, SPF modifiers may not contain any WSP at all, not even in the modifier value. In the "rf=" definition, I think it is questionable to REQUIRE ("MUST") report generators to generate reports in the first format from the list of preferred formats they are capable of generating. Report generators may have preferences of their own (for whatever reason), and there is no point in this document declaring a generator incompliant if it chooses to generate reports in a format *less* preferred by a domain owner even though it could theoretically generate a more preferred format. IOW, make this a "SHOULD". On the other hand, the last sentence specifying the case when no supported formats are requested should end in "then any reports MUST NOT be sent"; there *is* a point in declaring generators sending reports in unrequested formats incompliant. The same paragraph refers to a description of a reporting format registry in section 5, but section 5 does not establish such a registry. In the "ri=" definition, the semantics of the interval mechanism are weird. E.g., an "ri" value of 0 meaning anything other than "send no reports" is counterintuitive. Also the meaning of a value of 1 is unclear — does it mean "report on every failure" (like a value of 0) or "report on 1/2 of failures"? I assume this is because the mechanism was designed foremost to be easy to implement. However, I think it is more important that the mechanism be easy to understand by domain owners. A relative downsampling factor (a fractional number from 0 to 1) would be functionally equivalent but easier to understand by domain owners, while being similarly easy to implement. I see there is also talk about the possibility of an exponential backoff. Whatever satisfies the real world needs and is easy to understand. Consider making this extensible by syntax (e.g., by using a mode indicator as the "ri=" value's last character, so new modes can be defined in the future). Also, the meaning of "type of incident" is completely unclear. Does this refer to all SPF failures for the domain, or are SoftFail results to be tracked separately from Fail results? What about PermError results? Does this refer to the "ro=" types listed in section 4? If so, this is not clear. And are there perhaps even more elements to a certain "type of incident"? Does this interact with other authentication methods? Does a report on a message that failed SPF also count against the *DKIM* reporting interval if the message happened to also have failed DKIM? In the "ro=" definition, the ABNF grammar should be changed to make the "all" token mutually exclusive with a colon-separated list of tokens. Would it perhaps be more obvious to use the full SPF result code names instead of one-letter tokens? The "rs=" definition is suboptimal because the SPF grammar disallows WSP or quoted-atoms. While the current grammar specified by the "rs=" definition provides for this by requiring the value to be quoted-printable encoded (which turns whitespace into "=20"), this is still not very useful because any meaningful message would eat up a lot of space in the SPF record, which is already limited in size due to DNS limitations. I think it would be more useful to have "rs=" refer to a DNS name, under which a TXT record with the desired message will be found, similar to SPF's existing "exp=" modifier. That message should also be subject to macro expansion just like "exp=" messages. Finally, it would be more consistent (with "exp=") to then call this new modifier "rexp=" or "re=" or "rx=". In section 6.2, "Reports From Unrelated Domains", the scenario described is a problem only for domains referenced via "redirect=" modifiers, not for ones referenced via "include:" mechanisms, since section 3 explicitly specifies that r= modifiers in records found by following an "include:" mechanism must be ignored. However, perhaps section 3 should also say the same thing about records found by following a "redirect=" modifier, even though that makes specifying reporting parameters an inconvenience for domain owners who legitimately use "redirect=" a lot. Section 6.3, "Forgeries", commingles forgeries/fabrications and denial-of-service attacks, which are generally (as well as specifically in this context, as far I as can see) separate issues. What's the DoS issue in this context? The concern about forgeries remains unresolved. The section merely presents a few options, but then goes nowhere. I understand that the options presented (yet not mandated) are problematic. Does this perhaps *require* further discussion before this document is advanced? If no acceptable solutions are developed, then the section should be rephrased to merely warn about the possibility of fabricated reports and perhaps briefly explain why the apparent solutions were discarded. Section 6.4, "Automatic Generation", seems to appeal to verifying agents' sense of responsibility. This seems pointless. Perhaps this section would be better converted into a warning to domain owners publishing "r=" that large volumes of reports (legitimate or fabricated) should be expected. Similar things could be said about the volume related concerns in section 6.6, "Reporting Multiple Incidents". Section B constitutes a good opportunity for explaining the semantics of the "ri=" modifier as well as demonstrating the multiple-tokens support in the "ro=" modifier. Also, the positioning of the r*= modifiers within the SPF record insinuates that there might be a relevance to it. Per RFC 4408 there is not. Either state this clearly or move the r*= modifiers after the "-all" mechanisms. This will help avoid misunderstandings. So long, - -Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk4ZG2IACgkQwL7PKlBZWjtmIQCg18sZ9iDhNYMYcddK0AKnHxHS mz4AoPJPkqS0FCXaigl5ja1644Cv25FN =TZrF -----END PGP SIGNATURE----- _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
