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