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
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
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.
NOTE WELL: This list operates according to