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. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
