Tony Hansen wrote:
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=.
I think you may have landed on the core question (whew!) Is the i= value:
1. a single identity, or
2. a free-form identifier?
If the receive-side use case is to filter out mail from an untrusted domain,
then (as Suresh keeps saying) i= being anything besides the default probably
won't be very useful at all. Same story when the entire domain is trusted.
If the receive-side use case is to filter or prioritize different mail
streams or mail types within a single domain (such as transactional vs.
marketing vs. corporate, or the various customers of an ESP), i= can be
treated as a stable but opaque identifier. This also works for the AOL idea
of lumping especially trusted users into one identifier & especially
untrusted users into another.
If the receive-side use case is to prioritize mail from trusted individuals
within an untrusted domain (Grandma using a big ISP), or untrusted
individuals within a trusted domain (spammer using a big ISP), i= MUST a
single, stable identity, equivalent to the individual user ID.
What are the other cases we've all been talking past? Are there
sending-side use cases which vary dramatically from the above?
--
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