Douglas Otis wrote: > > 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.
Agree. So which part of my message are disagreeing which. I'm settle on what DKIM-BASE and ADSP is leaning towards. I've waited a long time to reach this point and although I am not at all happy with how diminished the POLICY component has become, I believe the most important policy (EXCLUSIVE declarations) is possible. So personally, I don't see what all the haggling is about about i=. > By having ADSP's reference the From email-address domain constrain d= > values, signing domains are provided full control over the i= value. Sure, but it still must comply as 4871 has it defined. I would of thought making it open ended would of satisfied the 3rd party market, but even that was screwed up. So it is what it is d=/i= have a specific compliance to it. > There is no reason for recipients to enforce i= value use beyond what is > currently defined by RFC 4871. Oh I see what you are thinking. I was thinking of terms of stupid software with no AI to it, no subjective meaning to it, no accessors involved and that is basically applying a deterministic algorithm as defined by DKIM-BASE for d= and i=. I'm sorry, if we are not talking about the same thing, I'm talking about non-subjective interpretations and simply following a deterministic protocol. 1 + 1 = 2, not 3. -- Sincerely Hector Santos http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
