On 04/06/2011 12:34 PM, Steve Atkins wrote: > On Apr 6, 2011, at 11:05 AM, Michael Thomas wrote: > \ > >> The alternative would be very squirrelly when you think >> of the general case of multiple signers in the path. >> > The approach I suggest has no problems with multiple > signers even if they, for some reason, all want to add > conflicting metadata. >
Yes it does. In your example, a second signer who isn't privy to whether it knows the birth date could either sign it because it wants to keep transport integrity, or not sign it because it doesn't actually know the veracity of the X-Birthdate: header. The receiver is then left trying to figure out who is asserting what, most likely by putting new rules/requirements on the DKIM signer. Messy and error prone. At least if you put it into the signature header you know for certain what the signer's intention is. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
