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=g...@aol.com, i=...@aol.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
