On Mar 11, 2009, at 11:59 AM, MH Michael Hammer (5304) wrote: >> On Mar 11, 2009 11:12 AM, Douglas Otis wrote: >> >> 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.
A signature lacking an i= value defaults to the d= value, but this does not represent a From email-address! As someone said, domains do not write emails, which leaves the "on-behalf-of" identity *undefined*. > There is nothing special about a DKIM signature missing an i= filed. > One simply uses the d= field. Seems pretty straight forward to me. Why must an i= value only represent a From email-addresses when present, when it is equally okay for the i= value to be omitted? When a DKIM public key imposes a g= restriction, the i= value MUST contain the restricted local-part or the DKIM signature WILL NOT be valid. It will be evident to an MUA whenever a restricted local-part does not match against a From header. It should also be safe for an MUA to annotate signed headers that match against the i= value, but not those that do not match, such as when the i= value is omitted or it omits everything but the d= value. In such cases, just the domain might be annotated. In either case, the i= value (on-behalf-of identity) might become declared as being opaque and thus defined as not representing a specific email-address. When the i= value is declared opaque, no email-address should be annotated, even when it happens to match against the i= value. >> 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. Oops. This has been corrected off-list since version 6. Section 3.2 now states Author Signature. Well, Section 3.2 will need to change back to Author Domain if or when i= value dependence is removed. By removing the i= dependency from ADSP, the assertions of "all" or "discardable" could then apply to any DKIM signature by the domain. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
