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 i=user(_at_)assessment(_dot_)example(_dot_)com(_dot_) 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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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 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
irrelevant.
Tony Hansen
tony(_at_)att(_dot_)com
Suresh Ramasubramanian wrote:
On Tue, Jan 27, 2009 at 9:30 PM, Jeff Macdonald
<jmacdonald(_at_)e-dialog(_dot_)com> 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