On Apr 6, 2011, at 9:07 AM, 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.
Not all new headers. (And the DKIM header doesn't really have any proper extensibility, and the use of single or two letter names for fields makes ad-hoc addition of new fields to that header - without a registry or version bump - quite a bit riskier than the "Full-English-Word:" approach 5322 headers use.) Rather, if anyone wants to release a specification that "requires" some sort of data be associated with a dkim signature then they can equally well release a spec that defines a new 5322 header that holds the same data. As a concrete example, if I wanted to include the authenticated age of each email sender (something the gambling industry might be interested in) then I can do that within the DKIM signature: DKIM-Signature: v=1; d=corp.example.com; <blah>; db=19700224 Or I can specify that that should be done with a dedicated 5322 header that both references and is signed by a DKIM signature. DKIM-Signature: v=1; d=corp.example.com; <blah>; h=To:Authenticated-Birthdate:<blah> Authenticated-Birthdate: version=0.1; dkim=corp.example.com; birthdate=1970-02-24 As long as the Authenticated-Birthdate header is included in the DKIM signature it references, that's pretty much equivalent as far as senders and receivers who are both using the same authenticated birthdate spec are concerned, just more flexible and less likely to clash with or break other DKIM usage. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
