Douglas Otis wrote:
Statements that imply the i= value is always OPAQUE prevents its
utilization for highlighting purposes with respect to identity
assurances, even when there is an exact match and this value could
be said to not be opaque. This also seems to conflict with the
defined use of the i= value as representing on whose behalf the
signature was added. There should be an exception spelled out for
exact matches.
Such as:
Hence, DKIM delivers to receive-side Identity Assessors responsible
Identifiers that are individual, where unless the AUID exactly
matches a signed header's email-address, is to be considered an
opaque value. Being opaque means the AUID sub-structures, and
particular semantics, are not publicly defined and, therefore,
cannot be assumed by an Identity Assessor.
Note that the text in rfc4871-errata currently says that the
local-part of UAID may or may not be in the same namespace as email
address local-parts.
You seem to assume that they're in the same namespace -- because if
they're not, comparing them does not make sense (exact match
or anything else).
(US passport numbers are 9 digits. US Social Security Numbers are
also 9 digits. But since they're not in the same namespace, an
exact match between passport 123456789 and SSN 123456789 does
not provide useful information -- the numbers could refer to
the same person (in theory, although unlikely) or to different
persons.)
So, even exact match with some email header is useless to the
recipient (unless it somehow knows that the Signer is using same
namespaces for these two fields).
Best regards,
Pasi
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html