I don't think I've made any such specific reference, since I agree that the examples you give are contrary to the definition in the spec.
It is already common practice for operators to segment their outbound traffic to avoid filtering issues. I expect them to apply similar segmentations with DKIM. The exact manner in which they should do that is what we need to agree on. If I choose to segment my signing based on my own assessment of the user, as I do now with outbound ip addresses, then I would probably make that a subdomain in d= (d=assessment.example.com). If I also choose to specify an i= value, then that segmentation will spill over giving us something like [email protected]. If my assessment of that user changes, then the i= value will change as well. So, i= does contain the identity of the user but is not necessarily a stable value. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony Hansen Sent: Tuesday, January 27, 2009 12:13 PM Cc: DKIM IETF WG Subject: Re: [ietf-dkim] draft Errata on RFC 4871 I think Suresh (and possibly Mike) are advocating a different sort of model for i= that I (and I think many others) have for it. They appear to be ignoring one part of the i= definition Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed and that's the word "identity". They seem to be replacing it with what appears to be an "assessment of the identity" as provided by someone else. Hence their references to [email protected], [email protected], etc. This is contrary to the spec. I fully expect the i= value, if it is present, to represent the identity of that user/agent. If a signer does not >>know<< the identity of that agent, I don't expect there to be a value for i=. If you don't >>know<< the user/agent identity, you cannot and must not put in a value for i=. If all you have is a gut feeling for the user/agent identity, you cannot and must not put in a value for i=. If you're a mail relayer, or a mail gateway, you cannot and must not put in a value for i=. The i= value can be opaque, but if it is present, most certainly is not irrelevant. Tony Hansen [email protected] Suresh Ramasubramanian wrote: > On Tue, Jan 27, 2009 at 9:30 PM, Jeff Macdonald <[email protected]> wrote: >> you lost me Suresh. It seemed like you were saying that i= would be >> useful for different streams or groups of identities but then you say >> "often irrelevant". >> >> I believe what i= means is irrelevant from the perspective of a >> receiver, but it does denote that something is different than a >> straight d= value. Is that your thinking too? > > Does my followup email (which I just sent) clarify things better? > > i= values MAY denote something different from a straight d= value, and > when there's a shared understanding of the i= values, and of the > underlying reputation model, d= will generally amount to sum(i= 1..n) > > But i= is entirely useless and, more importantly, untrustable without > some out of band trust worked out - either through a reputation vendor > certifying the i=, or through mutual contact (such as your setting up > a feedback loop with an ISP that bases its loop on dkim, and then > telling them what your signing policies are) _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
