Dave Crocker wrote: > > > Jim Fenton wrote: >> Section 4.3, "The Selector Construct", talks quite a bit about >> identities for doing assessments. > > Let's take care of the "quite a bit", just to make sure we are in sync > about the relevant text. > > The first paragraph merely says that d=/i= are used for making > assessments. The last paragraph does go into some detail about > providing differential identities, in order to support differential > assessment. I can see how that discussion might seem odd in this > section. > > On reflection, I'm suspecting there needs to be a separate > sub-section, along the lines of "Choosing names to be used for > assessment." > > The current text was motivated by the considerable community confusion > surrounding use of i=/d=/s= (as well as their complete independence > from From:, Sender: and the rest). Folks out there who are trying to > figure out how to make DKIM work are typically either very confused > about the issue or at just plain getting it wrong. The current text > was intended to try to clarify at least some of this. > > Not adequately, it would seem.
A separate section on "choosing names to be used for assessment" would definitely be preferable to having this information in the discussion of selectors. However, I'm not convinced that we have enough experience to give guidance on this just yet. > > > Other than the point that it makes in >> the section beginning NOTE:, none of this has anything to do with >> selectors. Furthermore, I consider it premature to define the >> identity(-ies) that might be used for assessments, not having >> operational experience with this (although I do agree that making >> assessments based on the selector is a Bad Idea). > > This re-introduces the basic question of what DKIM's output is. > Protocols have explicit input and output. Either DKIM is a complete > and precise protocol or it is some sort of fuzzy mechanism creating a > guessing game between signers and verifiers. This confuses the > higher-level task of assessing -- which will always be a bit fuzzy, at > best -- and the underlying act of asserting a responsible domain name. > > Since the DKIM specification says that its task is "permitting a > signing domain to claim responsibility" there had better be a very > precise way of determing what domain is doing the claiming. As soon > as there is more than one possibility, then it is no longer a serious > protocol. > > >> The last paragraph also suggests the use of different sub-domains for >> d=, but does not point out that the author address must also follow >> suit, otherwise the message may not be seen to be in compliance with >> Signing Policy. > > I don't understand. What is there in the DKIM signing protocol that > requires the author adress to "follow suit"? > Not in the signing protocol, but in ADSP. If an email with a From address of, say, [EMAIL PROTECTED] is signed with d=transaction.example.com then the signature cannot be an Author Signature. > >> Specifically, I suggest the removal of all but the first sentence of >> paragraph 1, and all of the last paragraph of the section. > > Since I believe that clarification of the role of the selector -- and > in particular making sure the reader knows that it is NOT part of the > assessment process -- your suggestion is problematic. Why? The second-to-last paragraph, beginning NOTE:, is the one that makes sure the reader knows that it is NOT part of the assessment process. And that paragraph remains. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
