On Mar 27, 2009, at 9:05 PM, Mark Delany wrote: >> >> I'll start by proposing text that we could use if we adopted an >> alternate definition of Author Signature based on the d= value >> only. Then I'll describe what I think we'll lose by going to that >> definition. > > Given that i= is an arbitrary value assigned by the signer, the > question to me is what value does it add beyond what signed RFC2822 > headers can do just as well. Eg, why not set an rfc2822.Sender > Field and sign that rather than invent i=? > > IOW, what is the value-add in inventing yet another identity called > DKIM.i= when we already have rfc2822.From, rfc2822.sender, > rfc2822.resent-from, rfc2822.resent-sender and rfc2821.mailfrom? > > Are you suggesting that DKIM.i= should have preference over signed > RFC2822 identifiers?
Yes. The RFC2822 may not be restricted. The i= value may match against these email-addresses within signed headers. The i= value may also represent a private namespace that represents accounts granted access. These accounts might not restrict email-addresses used within the signed headers. In either case, the i= value when present provides assessors a means to track accounts granted access. Without this ability, IP address associations will likely be needed to mitigate replay abuse. The use of IP addresses to mitigate replay abuse in not preferred, nor likely robust in dealing with CGNs and the like. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
