Barry Leiba wrote: > 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.
It's worth noting that the draft also doesn't prevent the Identity Assessor module from considering the List-Unsubscribe header, the phase of the moon, or absolutely anything else. That's a matter for the individual implementer to decide, not for the WG to dictate. > 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. That matches my recollection as well. > 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. Exactly. > 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. Thanks for these additional clarifications, Barry. Hopefully we won't have to cover this material again for a while. -- J.D. Falk Return Path Inc http://www.returnpath.net/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
