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
