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