On Tue, Jan 27, 2009 at 10:43 PM, Tony Hansen <t...@att.com> wrote: > 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.
In practice it ends up as "aggregation of a set of identities" to arrive at a usable / finite quantity for ISPs signing good, bad and ugly i=. And for senders it can be i=identity by all means, hopefully for a finite value of i But for legitimate senders (or even ISPs with decent control of their mail systems including smtp auth) there's no reason to doubt the identity of the user/agent and multiple different ways to authenticate it (such as dkim signing the headers) - so i= for that purpose is moot. And for any large mail system (sender or receiver) the potential values of i= tend to be very large indeed, large enough to make them unusable at the receiving side unless aggregated to some extent and layered with a reputaiton model. And it is the reputation model that's the bone of contention. A lot of senders appear to be under the impression that if they publish i= for individual clients of theirs, the bad reputation of one or more clients they have will not taint the reputations of other clients they host in a shared mail stream. >From a receivers perspective .. if that does happen, it is constrained within the limits of d= = sum(i=) and one or more clients with a sufficiently bad reputation will wipe out the good reputation of the other clients, especially when these are sent from adjoining IPs / the same CIDR. I am only sorry I participated in this discussion so late .. most of the discussion on the MAAWG mailing lists over the last several months hasnt shown me where too many receivers are fans of i=, except for the use case described above and some other corner cases. srs _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html