(I've changed the subject to take this out of the thread where it
didn't belong.)
On Fri, May 1, 2009 at 1:26 PM, Doug Otis
<doug(_dot_)mtview(_at_)gmail(_dot_)com> wrote:
Forgive the confusion about what was to be accomplished by the errata now
heading to the IESG. There was a vote in SF to _not_ make functional
changes to RFC 4871, and that such changes were to be as a RFC 4871bis
draft. The errata however, either through error or by intent, made a
significant change to RFC 4871 by excluding the i= value from being
information passed to the MUA. RFC 4871 indicates that the i= value IS the
information passed to the MUA
I understand your concern, Doug, but I think things are really OK
there. Here's why:
First, item 12 in the subject draft, updating section 3.9 of 4871, says this:
A receive-side DKIM verifier MUST communicate the Signing Domain
Identifier (d=) to a consuming Identity Assessor module and MAY
communicate the User Agent Identifier (i=) if present.
In other words, it's up to the verifier how to handle d= and i=, and
the verifier can certainly take i= into consideration in assessing the
signature.
Second, note that the Identity Assessor module, for which we clarified
the definition after San Francisco, is NOT the MUA, so be sure not to
confuse the two. The working group had consensus on the definition of
"Identity Assessor", with the recent update to it.
Third, remember that this update is trying to make a formal
distinction between the piece of code that does the "Identity
Assessor" function and any other code (including the MUA) that makes
other decisions. We'll certainly see the i= value included in
Authentication-Results headers, for example, and this text won't
change anything there.
Finally, the working group decided not to try to address any changes
to the "MUA Considerations" section, where we might talk more about
this sort of thing, because it's something that probably should be
pulled from the base spec in a -bis effort, and re-worked as an
informational document on its own.
So... I concur with you that the i= value may be important for
deciding how to handle the message, and I don't think the text in this
update changes anything in that regard. And I think the working group
expressed comfort with that as well, in arriving at consensus on this
text.
If someone disagrees with any of that and thinks the text should be
changed based on what Doug's said, please speak up right away.
Barry (as chair)
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html