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.sant9...@winserver.com Dkim-Signature: d=gmail.com i...@winserver.com Why is this not desirable/possible? Technically, I thinik gmail, probably should of done: From: gmail.sant9...@winserver.com Dkim-Signature: d=gmail.com i=sant9...@gmail.com because sant9...@gmail.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.sant9...@winserver.com Dkim-signature: d=mipassoc.org i=gmail.sant9...@winserver.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