Jon Callas wrote:
With DKIM i=, it becomes possible to convey a stable identifier
(though of
course there's no guarantee that the identifier is stable, leading
to John's
t= suggestion.) Without DKIM (or something like it), as we know, any
potential identifiers are trivially forged.
I want to point out as well that a stable identifier doesn't have to
be a field in the DKIM header.
It's trivial to make a new header for the stable identifier and have
that be in the list of headers signed.
I believe that this is even a *better* solution than trying to make i=
be something that it is and cannot be, and better than adding in a new
DKIM option.
That DKIM-base allows, supports, and encourages a way to have
additional headers that are signed is a major feature. We should
encourage it.
+1. DKIM-base also allows new tag/value pairs to be added to the
DKIM-Signature header field, so if somebody wants to define a tag for a
stable identifier to be used as a hint to reputation systems, that can
be done as an alternative to defining a new header field for this
purpose. This has the advantage that there's no confusion if there are
multiple DKIM signatures, there isn't confusion about which stable
identifier header field goes with which signature.
Note that I say this is a hint to reputation systems: Nobody can
prevent a reputation from using, or trying to use domain only, and one
can't require that the reputation system will actually pay attention to
a stable identifier, regardless of how it is expressed (in or with the
signature). Reputation systems that do a good job will succeed, and
those that do a poor job will fail. Note also that the stable
identifier would be effectively an additional output of DKIM verification.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html