On Wed, 2006-06-07 at 09:01 -0400, Tony Hansen wrote: > You have to differentiate between a DKIM-Signature header that's being > created and/or verified, and a DKIM-Signature that was there previously > and has now been included in the list of headers that are part of the > message being signed and/or verified. > > The b= nullification applies only to the DKIM-Signature being created > and/or verified. It does not apply to any other DKIM-Signature headers > that may be included as part of the message header. > > When I read -base, this seemed clear enough to me.
It would seem this is also not very clear either: ,--- | 3.7 Computing the Message Hashes | | 2. The "DKIM-Signature" header field that exists (verifying) or will | be inserted (signing) in the message, with the value of the "b=" | tag deleted (i.e., treated as the empty string), canonicalized | using the header canonicalization algorithm specified in the "c=" | tag, and without a trailing CRLF. | | All tags and their values in the DKIM-Signature header field are | included in the cryptographic hash with the sole exception of the | value portion of the "b=" (signature) tag, which MUST be treated as | the null string. All tags MUST be included even if they might not be | understood by the verifier. The header field MUST be presented to | the hash algorithm after the body of the message rather than with the | rest of the header fields and MUST be canonicalized as specified in | the "c=" (canonicalization) tag. The DKIM-Signature header field | MUST NOT be included in its own h= tag. '--- Where is the text that describes the different treatment of a previously existing DKIM-Signature header? -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
