I responded to Charles privately, but there seems to be more general
confusion (and perhaps some on my part):
On 2/4/09 11:15 AM, Charles Lindsey wrote:
On Wed, 04 Feb 2009 07:00:25 -0000, Eliot Lear<lear(_at_)cisco(_dot_)com>
wrote:
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).
First, I stuck to terminology that was in RFC 4871 intentionally, with
an eye toward keeping the errata simple.
Second, there is a predicate prior to the SHOULD NOT statement which is
important. However, it has been lost by more than one person indicating
lack of clarity. Let's try this again:
The contents of i= may not be a stable, and hence may not be
suitable for programmatic consumption on their own. As such, it is
NOT RECOMMENDED that verifiers consume the contents of i= without
additional external inputs that are provided by the sender.
Doug Otis cites the case I wonder as to whether it exists. One could
envision all sorts of things going on within the LHS of the @, like a
encrypted username with a nonce. I can't say whether anybody actually
does that or wants to do that.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html