Hector Santos wrote:
Yes, the i= value _is_ ignored when determining ADSP compliance. The
text that refers to the i= value is in RFC 4871, not the ADSP spec, and
the point of the note is to point out that the comments about the use of
i= there don't apply to ADSP because ADSP doesn't use i=.
I don't think we should have a note in a protocol that suggest, imply
anything NEGATIVE about not being compliant with DKIM-BASE. It is
works, it is compliant or its not. If we keep that statement that
people will undoubtedly think the protocol is now worth its effort,
especially when they do want to use i=.
Typo Rewrite and small follow up example:
Either it works and compliant or does not. If we keep that statement
then people will undoubtedly think the protocol is not worth its
effort, especially when they do want to use i=.
The technical problem as I see it is the tight requirement
between d= and i=. If i= is suppose to be an "On Behalf of"
idea, then it probably needs to be open ended.
For example, using my gmail account.
From: gmail(_dot_)sant9442(_at_)winserver(_dot_)com
Dkim-Signature: d=gmail.com
i=(_at_)winserver(_dot_)com
Why is this not desirable/possible?
Technically, I thinik gmail, probably should of done:
From: gmail(_dot_)sant9442(_at_)winserver(_dot_)com
Dkim-Signature: d=gmail.com
i=sant9442(_at_)gmail(_dot_)com
because sant9442(_at_)gmail(_dot_)com is my real gmail.com account, the from:
is
an authorized account I added to my gmail.com profile which gmail.com
performed an email verification.
But from a POLICY standpoint, if ADSP was a standard, GMAIL.COM would
do a ADSP check to see if WINSERVER.COM allows this.
So if ADSP is not supposed, I think gmail should be allow to add an i=
that is reflective of the real account holder. I don't think it has to
be a gmail.com domain as it would be in a mailing list.
From: gmail(_dot_)sant9442(_at_)winserver(_dot_)com
Dkim-signature: d=mipassoc.org
i=gmail(_dot_)sant9442(_at_)winserver(_dot_)com
Right?
What was the logic behind making i= be part of d=?
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html