> -----Original Message----- > From: [email protected] [mailto:ietf-dkim- > [email protected]] On Behalf Of Douglas Otis > Sent: Wednesday, March 11, 2009 2:13 PM > To: [email protected] > Cc: [email protected] > Subject: Re: [ietf-dkim] Moving on to ADSP - was RE: Handlingthe > errataafter the consensus call > > > 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. >
You are incorrect Doug. Look at RFC4871: If the DKIM-Signature header field does not contain the "i=" tag, the verifier MUST behave as though the value of that tag were "@d", where "d" is the value from the "d=" tag. There is nothing special about a DKIM signature missing an i= filed. One simply uses the d= field. Seems pretty straight forward to me. > 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. > I see no conflict. > 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. > <SNIP> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
