Tony Hansen wrote: > The semantics constrain the AUID to be an identifier for the agent/user. > This MAY be the email address of the agent/user of the message, or it > may be some other value that also represents the identity of the > agent/user but is not an email address of the agent/user. If it is the > latter, it is still required by the semantics to be an identity for the > user and must LOOK like an email address. But otherwise the localpart > and subdomain portion of the value are totally opaque in sense to DKIM > or users of DKIM. There is nothing else that tells us how we can look > into it and figure out what pieces of it means. [ . . . ] > How much you believe that i= value will necessarily be related to how > much you trust the verified d= value.
To put it another way: '...DKIM itself includes an additional identifier, the "i=" value, which looks like (but isn't) an email address. The signer can set i= to whatever they want, as long as the part after the @ is the same as the d= domain. Cisco uses this to identify individual users: [email protected]. More common, I'd expect, will be use of i= to denote distinct mailstreams or internal divisions: [email protected], [email protected], [email protected]. Thing is, i= is an opaque identifier. There's simply no way for anyone outside of the signing domain to know whether [email protected] is a mailstream, a department, a individual email address, or simply a string of randomly generated characters. DKIM does not tell you what it means, or if it'll mean the same thing in the signature of another message. DKIM does not tell you if i= is truth....' http://www.returnpath.net/blog/2009/03/searching-for-truth-in-dkim-pa-3.php (which is actually part 4.) Is anyone actually disagreeing with this? If not, what are we arguing about? -- 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
