deployment experience requires a stronger warning; that absent
additional information from the signer that is not exposed by this
specification, verifiers SHOULD NOT rely on i= as any sort of identity,
because the value may not be present or stable.
That's basically it.
2. Is the above statement actually true? Do we have practical
experience that shows that i= is either unstable or unused?
In my limited experience it seems to be reasonably stable when it's
used, but it doesn't reliably match other fields, and there are
significant signers that don't use it. Peeking at my inbox:
gmail no i= (many messages)
Cisco i=from address
my system i= stable but doesn't match any address
linx.net no i=
sendmail two signatures, no i= in either
So in this admittedly statistically invalid sample, most of the DKIM
signatures had no i=, only Cisco had a non-opaque one.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html