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, statements(_at_)example(_dot_)com 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