On May 1, 2009, at 11:43 AM, Barry Leiba wrote: > On Fri, May 1, 2009 at 1:26 PM, Doug Otis <doug.mtv...@gmail.com> > wrote: >> 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.
RFC 5451 passes information to "*Mail User Agent (MUA)* and downstream filters". The MUA consideration section now in RFC 4871 refers to information passed to the *MUA* as does the incorrectly transcribed by the errata. The Signing Identity (the i= value or its default), is what is defined as the information passed to the MUA. RFC 4871 clearly indicates the i= value is optional, and its default is an empty Local- part followed by an "@" followed by the domain from the "d=" tag. The errata erroneously transcribed Signing Identity as being SDID. Change RFC 4871 back to AUID, otherwise the information available to the MUA is being changed. The AUID always includes the SDID. The correct transcription for Signing Identity into the new terminology is AUID. > 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. Agreed. The new Identity Assessor terminology creates confusion. We both appear to agree an MUA is not an Identity Assessor. However, an MUA may include an Identity Assessor. > The working group had consensus on the definition of "Identity > Assessor", with the recent update to it. Currently, RFC 4871 indicates the AUID is to be passed to the MUA. The AUID, or its default, is assured to contain the SDID. Importantly, the SDID does NOT contain the AUID. This is a functional protocol change via errata. In this case, the errata reduces information passed to the MUA. In doing so, this potentially leaves the "on-behalf-of" identity ambiguous for recipients. This errata reduces clarity and weakens the protections being sought. > 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. But the errata IS functionally changing what is to be passed to the MUA. Defining the term "Identity Assessor" does not change what is currently defined as being provided to the MUA. By the errata changing Signing Identity (AUID) into SDID within the MUA consideration section, the information that MUAs might expect is reduced. It would be fine to replace Signing Identity with AUID or its default (@SDID) when not present. > 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. This was my understanding as well. This section should only replace "Signing Identity" with AUID to be consistent with the terminology changes. > 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. Agreed. Defining MUA details in the RFC 4871bis draft or perhaps some other draft as you suggested. Please don't make functional changes in an errata that has the effect of reducing user protections. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
