On Apr 12, 2009, at 9:21 PM, Hector Santos wrote:
In this case, the ADSP function might include part of the DKIM-BASE
checking and for ADSP that means d=/i= checking. The ADSP docs does
not talk about this approach because it is presumed this DKIM-BASE
work was already done.
IMV, the ADSP docs should have semantics about what i= means -
technically:
From.domain == d.domain == i.domain (or subdomain of d=)
Disagree. Constrains on the i=value are well defined by RFC 4871.
A domain within the i= value MUST be at or below the signing domain,
and when the "s" flag is set within the key record's t= value, a
domain within the i= value MUST NOT include any sub-domain for the
signature to be valid.
By having ADSP's reference the From email-address domain constrain d=
values, signing domains are provided full control over the i= value.
There is no reason for recipients to enforce i= value use beyond what
is currently defined by RFC 4871.
From what I see here, most agree, it doesn't have to mention i=
because its implied that it will comply with d= and d must comply
with from.domain.
Agreeing with the majority, and when Authentication-Results headers
are considered, reasons for further constraints on i= values diminish.
It is more important to ensure the i= value retains its defined
function of indicating on whose behalf the signature was added. A
message might be signed on behalf of the Sender header, for example.
The i= value might even represent a token for this entity. DKIM is
never claimed to identify individuals, however a token can still
assist in mitigating intra-domain abuse.
Some might optimize by checking the d= value for ADSP compliance, and
the i= value for key record t= compliance prior verifying the
signature. Some might even check the d= domain reputation which might
also signal a need to check the domain's i= reputation. A reference
to the i= value could use the hash label defined for third-party
authorization, for example.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html