Michael Thomas wrote: > On 04/06/2011 08:48 AM, Steve Atkins wrote: >> That sounds like a fragile way to extend things - leave a >> little used feature around and hope someone who wants something >> new hijacks that field in a non-conflicting way instead. (Which >> may not be what you're suggesting, but it's an implication I've >> seen in some comments about i=). >> >> Outside of the information that is needed to validate the DKIM >> signature (v, a, b, bh, c, d, h, l, q, s, t, x) there doesn't >> seem to be any real need for information to be recorded in >> the DKIM-Signature field at all. Rather, it can >> use the 5322 extensibility to add a header containing the information >> that needs to be included (with an understanding that the receiver should >> require that header be covered by the DKIM signature).
> There is something to be said about using tags in the signature > rather than signed headers. Signers don't have to have any > reason -- and none should be inferred -- for signing any given > header. There are no semantics associated with that. Putting > something in the signature on the other hand carries > the exact semantics of what the value means _in the context of > the DKIM signature_. > > So unless we want to start making new headers have a presence > of a DKIM semantics requirement -- which would probably be > hopeless -- it's probably better to keep extensibility within > the narrow confines of the DKIM header itself. Since DKIM provides mechanism for signers to achieve that authenticity outcomes independent for their reasons for standard features or extensions, I think both points are valid but with a difference of one having a higher or lower threshold for authenticity verification. So from this aspect, I would tend to agree with you that it would be probably better when extensions use the DKIM header. Authenticity related to confining extensions to the DKIM header would be easier to reach and "harder" to reach when using extra headers because it presumes the extra headers will be persistent (passthru) along the path, hence why we have a recommended set of commonly known RFC 5322 headers to bind and expected to survive. I hate to be anal about it, but all that made sense when Policy was a principle focus and not Reputation because Policy allowed us to grasps and deal with DKIM authenticity failures. But now with reputation coming out of the closet as the WG accepted primary focus and everything related to DKIM; the proposed standard and helper RFC documents, its now only about assessing a positive authenticity with a trusted signer domain identity source. The mindset is now there is a lesser need to consider anything else. In short, since reputation does not deal with authenticity failures, domains should be wiser regarding raising authenticity complexity and verification thresholds because reputation can't help you when things go wrong. The lack of concern for dealing with faults or authenticity failures, makes it easier to consider removing or reducing the failure points which appear to have no value. -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
