Douglas Otis wrote: > On 4/7/11 10:08 AM, Murray S. Kucherawy wrote: >> You could, if you know that the use of "i=" by a given >> SDID is consistent, and it's useful for you to track per-AUID >> reputation. Those are two big "if"s to me.
> Murray, > > Anyone processing this type of data will quickly determine whether the > i= field provides value with respect to correlation. +1 > Nothing is perfect and it would be unfortunate to have it > deprecated for that reason. +1. I think I will change my support to keep as is or keeping it with better semantics that do not cause compatibility issues with legacy verifiers. That mean not changing the d=/i= relationship definition as this will break software. DKIM "perfections" will continue to be difficult challenge as long as the various deployment motivations are in conflict, more specifically when the motivations for the trust come at the expense to ignore or outweigh the motivations for securing protected bits. IOW, a motivation for i= or adding any other signed bit (header or tag) may simply be a domain desire to increase the authenticity challenge. After all, when authenticity fails, any motivation for trust based policy semantics "I expect you to trust the signer domain" can not be applied. -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
