(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 <[email protected]> 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
