Peter Blair

Learning to use DKIM usually involves a lot of trust in a process that may not be fully understood by the operators. I hope to lift the veil by implementing a step by step application to demonstrate what is being done and why.

Please download the following perl script:

And execute against any saved message that contains a DKIM-Signature:

In the first screen, we’ve simply extracted the DKIM-Signature header from the email, and displayed it for informational purposes.

Once in the second screen, we’ve split the header out, and fed it into a hash reference.  This contains the values that we will be operating with during the verification process.

The next part is the generation of the body hash.  This hash is stored in the DKIM-Signature, under the bh= field, and is used to verify that the content of the body did not change once the signature was generated.  This is done by looking at the a= field to determine which digest algorithm to use, then the result is base64 encoded in order to be printed within the email header.

But! Before we can generate the digest on the body, we must agree upon the representation of the body.  Difference MUAs might change the body around, treating whitespace differently etc.  So what we do is we canonicalize the body first.  The c= field shows which algorithm to use when canonicalizing the body.  In this example, we want to use the “relaxed” method implemented in the script.  This is documented under 3.4.4. The “relaxed” Body Canonicalization Algorithm of the DKIM RFC.  The script outputs the relaxed lines, surrounded by brackets to show where the lines start and end.  Note that it does so in reverse order.  This way we can strip out all tailing blank lines, per the RFC.

Once a canonicalized representation of the body has been established, we generate the digest (in this case, sha256) then base64 encode the digest.  If this value matches the value of bh= then we know that the body has not been altered since the time of the message signing!

The script is currently only implemented through the body hash section.  Next is the header relaxation, and signature verification process.

Please stay tuned for updates!