On Tue, Jan 27, 2009 at 10:43 PM, Tony Hansen <tony(_at_)att(_dot_)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=good(_at_)aol(_dot_)com,
i=coi(_at_)aol(_dot_)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