Jim Fenton wrote:
I do feel that we're effectively
using "assessment" as a proxy for "the R-word" which goes back to the
concern I voiced long ago about not requiring the verifier to pass on
other values including i= if they're present. It seems to me that this
is effectively dictating the operation of the (wink wink, nudge nudge)
assessor. But I won't belabor that, since it seems that the rough
consensus felt otherwise.
Thanks for not belaboring it.
I won't either:
1) DKIM states the goal of delivering an identifier. Not a mass of
interesting
attributes for the assessor to pick and choose among. The clarification
distinguishes between the (one) formally delivered identifier, versus whatever
informal (outside of the spec) ad hoc, local usage the receive-side might wish
to engage in.
2) This is not telling the assessor what to do with the identifier, but making
sure the assessor and the signer treat the same identifier as the primary one.
3) The spec failed to distinguish between internal mechanism versus payload.
This corrects that.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html