On Mar 11, 2009, at 10:15 AM, Dave CROCKER wrote:
Isn't it much simpler, and entirely sufficient, to have ADSP use
SDID (d=)?
I am not understanding the downside to the choice.
The alternatives all seem significantly more complicated and
probably problematic.
100% agreed. : ^)
Depending upon the interpretation given for Section 3.2 of ADSP, any
valid DKIM signature from the Author Domain may omit ADSP record
transactions.
The only logic for requiring either a DKIM signature that lacks an i=
value, or one that matches against the From header, would be there is
something special about a DKIM signature that lacks the i= value.
There does not appear to be any rational semantics to explain what is
implied when the i= value is missing. On that point, Dave is correct.
Since the ADSP draft is already internally in conflict on this point,
a simple solution would be to drop the i= value requirement in ADSP.
If the DKIM i= value becomes defined as always being opaque, then ADSP
will need to define some other tag to introduce a non-opaque namespace
if DKIM is to be seen a method to affirm an email-address. Defining
i= values as always being opaque is not really needed. After all, a
valid signature does indicate the entity applying the signature is
acting on behalf of the owners of the email-address namespace.
The present DKIM draft could be clarified as offering an i= value that:
a) represents a real email-address whenever it matches against a
signed header field within the message, or
b) represents an opaque identifier whenever it does not match against
a signed header within the message.
This clarification avoids a need to create a new tag, and still
permits those implementing ADSP a means to affirm an email-address,
but _only_ when the i= value matches exactly with signed header field.
Since there are those that do not want to extend the use of DKIM In
this manner, ADSP would need to be seen as allowing a domain to only
enforce a signature requirement. Either affirming an email-address
or just enforcing a signature requirement would be fine, but there
should be agreement about what is intended goal of ADSP.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html