Murray S. Kucherawy wrote: > [as regular participant, not document editor] > > Moreover, it's substantially more than the percentage that > appear to be using "x=", but we're not considering removing > that here. > > So it seems like we've got this theory that simpler > is better, but we're applying that theory piecemeal. >
It may not be your intent, but lets not indirectly instill the idea x= should be a considered candidate for removal. This DKIM feature has an easy understanding, feel and grasp for utility. It is easy to explain to producers and consumers, easy to employ and simply something people can actually use if so desired. i= is a much different issue. For its functionality, I can't speak I had a full understanding for its use cases other than an intent for user level signings. I also never understood why it remained over the years when it seemed to be something yet fine tuned and there was still the long time concerns of its DNS scalability. Yet, it hung around but seem to become one of the DKIM features that would not be used much. From the software angle, when the key record g= tag is no longer part of the spec, then i= is less software wise required. Can't speak for OpenDKIM, but in the ALT-N (verifier) API, any i= value defined in the signature is only applied when a key record g= tag value is defined. From the testing standpoint, I found a need to modified the API to add an verifier CheckGranularity=1|0 option because we found false positives with computational valid signatures but an failed NO SIGNATURE result due to a failed g=/i= granularity wildcard string comparison checks. The check option was provided with a noted concern it might promote a security loophole if disabled. From a documentation standpoint (F1 online help, etc) in describing the what, why and when to use reasons for his particular i= option, was not easy to do especially when it came to the DNS management aspects. -- Hector Santos http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
