Jim Fenton wrote:
There remains some disagreement on whether the "informative note"
contained in the last paragraph of the text I proposed on March 27
should appear in the ADSP draft. The note said:
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.
This would replace the Note in draft-ietf-dkim-ssp-09, section 2.7.
Thus far, I feel it should be included and John Levine and Dave Crocker
feel it shouldn't. May we have guidance from others in the Working
Group, please?
My input:
Maybe I don't quite see the issues, but I've been doing more testing
later to see how this is all going to fit, and there seems to be a
need to deal with issues for the high potential cases:
1) same primary domain name spaces
From: user @ subdomain.primary-domain.com
DKIM-Signature: d=primary-domain.com
or
From: user @ primary-domain.com
DKIM-Signature: d=subdomain.primary-domain.com
2) "3rd party" or non-author domain name space
From: user @ primary-domain.com
DKIM-Signature: d=some-other-domain.com
As far as the i= is concern, as long as the h= binds the From: header
(as it must per 4871) the i= appears to me as an "extra" bit of
information that is not required for DKIM 4871 verification.
Lacking applications for usage, I don't see how i= "helps". I think I
understand some people want to use it as feed to some future or
current trust service in the works. But I see that as gravy information.
If the "issue" relates to non-author domain signatures, then of
course, I will always continue to believe we have neglected to resolve
the 3rd party design issue from a "Fraud Protection" standpoint. Not
the whitelisting part of that design, the blacklisting. No one wants
to hear that (at least here) and thats unfortunate because in all my
engineering experience and logic tells me, that is will continue to be
a thorn on (DKIM) side and in my view, the #1 threat to DKIM wide
acceptance and adoption. I would think that would mean something to
the marketing of DKIM. But thats me.
If the i= is suppose to address that Jim, then I will love to hear and
understand it because currently I don't see how that helps.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html