+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