+1 Based on SM's excellent summary review, I change my original A entry to D.
Thanks SM. -- Sincerely Hector Santos http://www.santronics.com SM wrote: > At 08:36 16-02-2009, Stephen Farrell wrote: >> We've had some recent discussion about d=/i= on the list >> and a couple of concrete proposals for clarifications to >> make to RFC 4871. >> - The first is Dave's erratum I-D. [1] >> - The second is a proposal from Eliot.[2] > > [snip] > >> So, can you please reply to the list with *one* of the >> following opinions, before the end of next Monday, Feb >> 23rd. >> >> (a) The erratum I-D [1] is ready to go. Process it. >> (b) The erratum I-D [1] is the way to go, but needs work. >> (Then specify your changes in "NEW"/"OLD" style.) >> (c) Eliot's proposal [2] is ready to go. Process it. >> (d) Eliot's proposal [2] is the way to go, but needs work. >> (Then specify your changes in "NEW"/"OLD" style.) >> (e) None of the above. > > The erratum (draft-ietf-dkim-rfc4871-errata-02 - item a) introduces > new terms such as the User Agent Identifier, Identity Assessor and > Signing Domain Identifier. It then goes into an explanation of how > they tie into DKIM. Eliot's proposal (item c) falls within the usual > boundary for an errata as it tries to provide clarity without > introducing new terminology. > > An errata is generally noncontroversial. Instead of being a > clarification of the d= and i= tags in the current specification, > this one turned into a determination of how DKIM will be used in > future. One of the proposal affects the work currently being done on > ADSP. I'll quote Section 2.7 of draft-ietf-dkim-ssp-09: > > "Note: ADSP is incompatible with valid DKIM usage in which a signer > uses "i=" with values that are not the same as addresses in mail > headers. In that case, a possible workaround could be to add a > second DKIM signature a "d=" value that matches the Author > Address, but no "i="." > > With the change, we may need to sign the message more than once in > some circumstances if we are using the i= tag. That's an extra > overhead both for signers and verifiers. > > Quoting part of Jim's proposal: > > "In many cases, the i= tag will not be present in the DKIM-Signature > header field at all; it is not required unless the signing key > restricts the signing identity or identities via its g= value." > > That is better suited for a document about deployment. > > J.D. suggested leaving i= opaque and see what operators (on both ends > of the transaction) do with it. That could be discussed in a > document about deployment. > > Given the scope of Dave's proposal, I'm still not comfortable with it > as an erratum. I choose Eliot's proposal (d). > > Regards, > -sm > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
