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