John Levine wrote:
Informative Note: ADSP is incompatible with DKIM signing by parent
domains described in section 3.8 of [RFC4871] in which a signer uses
"i=" to assert that a parent domain is signing for a subdomain.
That's not fine, since we've just gone around and agreed that the
signing identity is d=. leave this paragraph out.
Yes, please, on two counts:
1. The definitions that the group has just agreed to no longer calls i= a
signing domain of any sort. I am hoping that no one is suggesting that ADSP
redefine core constructs of the revised DKIM signing specification.
2. By its nature, ADSP imposes some constrain on DKIM use. It is, after all,
defining an equivalence between a DKIM value and a RFC5322.From value. The
question is which DKIM value. As soon as there is ANY equivalence with the
From
field, a number of scenarios will be incompatible. The one that Jim is citing
is just that: merely one. And it's one that might not be correct (see below.)
If we are going to add an Informative Note like he is suggesting, we are
going
to have to do an extensive audit to make sure we cover all of the implications
-- and there really will be more than just this one. I don't see the benefit
of
doing that and suggest, instead, we leave off such efforts at being selectively
helpful.
As for possibly not being correct, the phrase "parend domain is signing for a
subdomain" hinges on the "for". It goes to intent as well as implying some
details about the i= value that well might not be applicable. Yet DKIM does
not
specify that anything about deeper semantics, such as intent, about the
relationship between SDID and AUID values. So, again, we would do well not to
rely on any particular ones.
In general, I suggest that suggestions for interpreting DKIM start by
explaining
how a receiver is going to know that that explanation holds true.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html