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
