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