Douglas Otis wrote:
Yes, the ADSP specification is complete without this note (it's
informative, after all). But the compelling argument that justifies
it is that it clarifies things in a way that may improve
interoperability. We should be trying to write specifications that
promote interoperability, not just ones that are technically complete.
The ADSP compliance issue is limited to a relationship between the
From email-address domain and the signing domain. This relationship
is not defined in the base draft and is not related to the i= value.
But it is, indirectly.
Consider the possible migration with existing DKIM systems that may
adopt ADSP when its all said and done.
Currently, the ADSP ignorant DKIM-BASE verifier will do a verification
and per 4871 should perform DKIM syntax/format tests including the d=
and i= domain comparison and compliance test. If it fails d=/i=
compliance (for whatever reasons), the signature is invalid.
Come ADSP support and the DKIM-BASE implementation MAY update the
design to focus on optimization by performing an ADSP lookup in call
cases prior to any heavy message rehashing/crypto processing.
This optimized ADSP implementation design will require it to do the
DKIM-BASE syntax checking including d=/i= comparison test among the
other DKIM-BASE checking possible. If both of the following is TRUE:
ADSP => DKIM=DISCARDABLE
DKIM => syntax, formation checking fails
Then there is no need to do any DKIM rehashing, the ADSP/DKIM test
condition is satisfied and the message is rejected/discarded.
IMV, there will be a minimum of two possible implementations;
1) Functionality is separate, one feeds the other
DKIM_BASE_RESULT = DKIM_BASE_VERIFY(payload)
DKIM_ADSP_RESULT = ADSP(DKIM_BASE_RESULT, payload.from.domain)
2) Functionality is integrated or updated as one function
DKIM_ADSP_RESULT = DKIM_ADSP_VERIFY(payload)
Some people in the first group will probably not touch the DKIM-BASE
mailbots, API or software, and only feed the result to an separate
POLICY mailbot that only need two parameters - the result of DKIM-BASE
and the payload from domain. The ADSP functional specification is
geared towards this group with the incremental approach to adding
policy to an existing DKIM-BASE implementation.
But for people who waited and/or more incline to see the whole
picture, do more integration, do the optimization at the start, not
later, this group will update their current software, API, etc, and
perform the steps in a different order. As long as end result is the
same - it should not matter.
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=)
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.
But I think it should for better understanding of ADSP as it relates
to DKIM-BASE.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html