I tracked down a problem I experienced with one specific sender. Most of their mail passed the DKIM checks all right, but as soon as
there are two DKIM signatures (at internal forwards), the top DKIM (the one added the last) fails Exim's DKIM test with
"signature_incorrect" (header modified in transit). On the other hand, the DKIM aligns just fine with DMARC, and the message passes
a check by dkimverify.pl, too (it uses Perl Mail::DKIM::Verifier).
I've run the concerned message through Exim with "exim -d-all+acl -bhc <IP>", and found out that although the top signature's h tag
includes also the first (bottom) signature (h=DKIM-Signature:...), Exim's PDKIM incorrectly fails to include the bottom signature
into the header hash of the top signature.
Below are the "h" tags of both signatures (full signatures attached at the end of the message):
h= DKIM-Signature:Received:From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:X-Mailer;
h=Received:From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:X-Mailer;
And here comes the PDKIM output for the upper signature (shortened for briefness and because of privacy reasons, but I can provide
the full version to the developers):
DKIM >> Hashed header data, canonicalized, in sequence >>>>>>>>>>>>>>
received:from{SP}[192.168.1.11]{SP}(46.157....
from:Dan{SP}H...
content-type:multipart/alternative;{SP}...
mime-version:1.0{SP}(Mac{SP}...
subject:=?utf-8?B?TmVqbG...
message-id:<AC48C5A5-24FF-...
date:Fri,{SP}13{SP}Jan{SP}2017{SP}17:18:37{SP}+0100{CR}{LF}
to:Libor{SP}P...
x-mailer:Apple{SP}Mail{SP}(2.3259){CR}{LF}
PDKIM <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
As you can see, the first DKIM is not included. In fact the header hash data is identical to the header data of the bottom
signature, although it should have the other DKIM included at the beginning.
And of course, as expected, the hash of the header fails with the following error:
headers verify: error:04091068:rsa routines:INT_RSA_VERIFY:bad signature
PDKIM [seznam.cz] signature status: PDKIM_VERIFY_FAIL (PDKIM_VERIFY_FAIL_MESSAGE)
Although I was pretty sure the problem was with Exim's PDKIM (both DMARC and Perl worked fine), I checked the DKIM standard RFC6376,
to verify how exactly such cases should be processed. In the chapter 4.2, it tells:
" Note that Signers should be cognizant that signing DKIM-Signature
header fields may result in signature failures with intermediaries
that do not recognize that DKIM-Signature header fields are trace
header fields and unwittingly reorder them, thus breaking such
signatures. For this reason, signing existing DKIM-Signature header
fields is unadvised, albeit legal."
So, although the singing of another DKIM is not recommended, it is not forbidden, hence Exim must be really adding it to the header
hash, when declared.
Unless someone tells me that I have overseen something important, I am going to submit a bug report.
Regards,
Ivo Truxa
Full signatures:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seznam.cz; s=beta;
t=1484324327; bh=0cKQZA3974kPpHVku7d2ygQjue5EGjWi9kzuNj8Qs9o=;
h=DKIM-Signature:Received:From:Content-Type:Mime-Version:Subject:
Message-Id:Date:To:X-Mailer;
b=eieG+FOECPFsiBuyiQDdJ8YN8WvTCt2OYh2SDoOtVKnZEx6dzGiZQmq6es1KBAEav
XgK6fTUGftxkVc+GOVeQ3xEPXgUhgbqifaNo12ZKsYoYtWWJkvEN7PfyN2M5B6utHm
d53m+zTY/+XSVYINKyKJiraes6noV9h83zZsHBbs=
DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=seznam.cz; s=beta;
t=1484324319; bh=0cKQZA3974kPpHVku7d2ygQjue5EGjWi9kzuNj8Qs9o=;
h=Received:From:Content-Type:Mime-Version:Subject:Message-Id:Date:
To:X-Mailer;
b=ZaF4KCCPl4aMC6U+sjFcEuG5z9XHYEHi2u68U1zE0He6SBpTp1jze0iw2Pke/RODA
5KmtKQp/it6hPnNWu1xdsb8m0BXzLVnspExreYZ3jJfn9mBdgO0BHl9c8urOgi6vXo
y1IMs492tD6uoytRxmmJMqNvcWey/krKTtgFCc7k=
