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
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.
NOTE WELL: This list operates according to