On Feb 4, 2009, at 2:15 AM, Charles Lindsey wrote:
On Wed, 04 Feb 2009 07:00:25 -0000, Eliot Lear <lear(_at_)cisco(_dot_)com>
wrote:
Here, the consumer of this information, the verifier, is warned
against making use of i=. However, what we are now saying is that
practical 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.
No, SHOULD NOT is too strong. Normally, that would indeed be the
case, but in specific cases the Assessor (not the Verifier) might
have information, obtained by some out-of-band means, what that
particular i= meant, and be able to act accordingly. Otherwise (and
maybe always), assuming the d= matched satisfactorily, the i= should
just be passed on to the end user who might make some sense out of
it (e.g. Aunt Tillie vs Uncle George).
Charles is correct. Currently RFC 4871 states the signer can use this
optional value to indicate on whose behalf the signature is added.
The fact that the identity contained within the i= value may be
understood only by the signer would be a secondary issue that does not
detract from an ability to mitigate abuse from signer recognized, but
otherwise anonymous, sources. However, when the i= identity is
understood to represent an email-address contained within the message,
such Aunt_Tillie@ or Uncle_George@, then the "SHOULD NOT RELY on i="
admonishment would be in direct conflict with the existing RFC. The
i= SHOULD always indicate in some undefined manner, on whose behalf
the signature was added whenever this value is added to the
signature. The identity represented by the i= value may or may not be
opaque to the recipient.
The use of fictitious subdomains within the i= value would be a simple
way to ensure there are no name collisions. For example,
i=0123456789(_at_)radius(_dot_)example(_dot_)com
could be used when the i= value represents a Radius account number.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html