[ietf-dkim] ADSP Informative Note on parent domain signing
hsantos at santronics.com
Sun Apr 12 23:33:40 PDT 2009
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 -
>> 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.
More information about the ietf-dkim