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 i=good(_at_)aol(_dot_)com,
i=coi(_at_)aol(_dot_)com, 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
Suresh Ramasubramanian wrote:
On Tue, Jan 27, 2009 at 9:30 PM, Jeff Macdonald
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
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