-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Kitterman wrote:
> On Tuesday, June 28, 2011 09:35:07 AM internet-drafts@ietf.org 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-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110709232442:25D07A18-AAA4-11E0-9ECA-756BF559ED1D
Powered by Listbox: http://www.listbox.com
Hash: SHA1
Scott Kitterman wrote:
> On Tuesday, June 28, 2011 09:35:07 AM internet-drafts@ietf.org 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-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110709232442:25D07A18-AAA4-11E0-9ECA-756BF559ED1D
Powered by Listbox: http://www.listbox.com