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