Arvel Hathcock wrote:
Yet more suggestions:
4.1 DNS Representation
"Sender Signing Practices records" -> "Sender Signing Practices
Records" (assuming you agreed to the previous suggestion of making
this an explicit definition change in 2.7).
Agreed.
"Records not in compliance with that syntax or the syntax of
individual tags described in Section 4.3 MUST be ignored" This
seems like you're saying two things: First, records with overall
syntactic problems (like SPF record put into SSP location) should be
ignored. Second, that records with individual tags that are not
syntactically correct result in the entire SSP record being ignored
(rather than the specific tag in question being ignored). Is this
what you mean?
No, it isn't, I meant what Section 4.3 says, which is, "Unrecognized
tags MUST be ignored," although I mean that the lack of a tag which is
REQUIRED does invalidate the entire record. I'll correct the inconsistency.
"for purposes of message disposition," - I would just delete
this bit as it's not necessary and could stur up the distaste some
have with the entire question of SSP determining message disposition.
Uh, OK. I guess it's not strictly required.
"SSP records for a domain are published at a location...." - I
keep forgetting where this is and trying to find it in the document is
not as easy as it could be yet this is a major issue of practicality.
I think this is just my own stupidity coming into play but perhaps
this point could be highlighted with a 4.1.1 and a title of like "SSP
location in DNS" and maybe it should be put into 4.2 since that
section is entitled "Publication of SSP Records".
I agree it fits in section 4.2 and will think about how to structure that.
4.2 Publication of SSP Records
I see we have done away with the tree-walking completely which I
think is great.
:-)
4.3 Record Syntax
So, if I encountered an SSP record with dkim=foo this value is
invalid and so the SSP contains a tag that is syntactically
incorrect. This causes the rejection of the entire SSP record
right? If so, I think this should be made more clear because I
missed it. Is this what the text in 4.1 is saying?
The syntax of the tag-value is incorrect, so it should be thrown out,
and since the tag is REQUIRED that renders the record invalid.
The descriptive text for "all", "strict", "process" should be
indented some to aid readability.
I'm probably limited there by what XML2RFC does.
Non-Normative Rationale: Strict may also be used by domains who
simply don't want their domain spoofed. Not sure if you want to say
something about that or not.
I'd rather not say that because it depends on the definition of "spoof",
which is a can of worms. You'll notice that "spoof" is not used in a
normative context in the document.
The section on "process" says that messages "SHOULD be processed by
the verifier" - that's good because this is what got us the result of
"process" in the first instance :P
Suggested rewrite: process - Messages which are Suspicious
from this domain SHOULD NOT be rejected although an SSP failure MAY be
considered in subsequent evaluation of the message.
It does sound a bit circular, but if we had used the keyword "foo" you
probably wouldn't have had a problem with the word "process" in the
definition, right? I don't think we should have to approach the
definition indirectly just because we chose a mnemonic keyword. Also,
the definition you propose doesn't have the exact same meaning. The
current definition boils down to "do what you would normally do with the
message, but consider the SSP result if you want" which is different
from "SHOULD NOT be rejected" since what one might "normally do" might
include rejecting the message.
"intende" -> "intended"
Can't find that -- did your printer cut it off?
Suggested rewording of the t=y text:
"The domain is testing Sender Signing Practices and the message
SHOULD NOT be considered Suspicous based solely on it's results."
Solely? SSP is the sole determiner of Suspicious (which I should have
capitalized), so I'm not sure what you're getting at. How about:
"...the Verifier SHOULD NOT consider the message Suspicious."
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html