Auteur: Phillip Carroll Date: À: Exim Mailing List Sujet: [exim] DKIM in exim: Broken?
I run an exim mail server on my company domain, which supports a small
family business, plus the personal email of my spouse and myself. The
total amount of email traffic is trivial compared to probably most of
the recipients of this mailing list.
Our method of MUA connection is somewhat unorthodox. We use an SSH
client to log into the system via localhost, use a single user ID on the
server, and use port-forwarding of SMTP for submission, and IMAP for
local receipt and sorting. None of which has any bearing on the topic at
hand.
I am trying to implement exim-based DKIM checking in an intelligent
manner in support of the above. For instance, my primary banking
institution (JP Morgan Chase) sends us DKIM signed emails (some
business, some personal). It is obviously desirable to be able to have
assurance that any emails I receive that claim to be from Chase are in
fact genuine. Which seems to be the point of DKIM signing.
Yet, this appears to not be possible with the version of exim I am using
(4.80.1). I have the DKIM checking enabled, I know that the emails I am
looking at were sent with valid signatures and have not been altered in
transit, yet exim asserts (in the log) for each and every email we
receive from Chase:
[verification failed - body hash mismatch (body probably modified in
transit)]
The emails all use rsa-sha256 with c=relaxed/relaxed. The signed headers
are:
h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding
All of these headers are straightforward, non-repeated, and easily found
in the email. I am absolutely certain that none of these enumerated
headers nor the body text have been altered en route.
However, all of these emails pass through a chain of Chase mail relay
servers (easily seen from added Received: headers), with the last of
these transmitting directly to my server with:
esmtps (TLSv1:DHE-RSA-AES256-SHA:256).
The earliest Chase Received: header in each email I have seen is
immediately below the DKIM-Signature: header, the signed headers in a
group just below that, the second Chase Received: just above the DKIM
signature, and my server's Received: header just above that. Along the
way (or perhaps initially) Chase adds a few more (unsigned) headers for
internal use, and my exim config adds a few more, both at top and bottom.
I am finding this to be a defining feature of all emails that fail DKIM
checking, namely, there are added headers.
Could someone who understands the exim DKIM support explain coherently
why a valid DKIM signature in an email that contains headers added in
transit (above, below and interspersed) always fails verification? I can
understand verification would certainly fail if someone in transit
altered any of the actual SIGNED PORTION of the email. Which would seem
to be the point of signing. What I can't understand is the inability to
accurately verify the signing of the unaltered body and specified headers.
From a Google search of the mailing list archive, it seems the
universal advice is (loosely interpreted by me): "the exim dkim support
is broken such that you can't use it to verify, for example, any
signatures contained in postings to this mailing list, or any other
mailing list".
Basically, I am asking:
(a) Is the exim dkim support simply broken in this regard?
or
(b) Is is it possible I have set up the configuration wrong? (emails
that do not have extra headers all seem to verify ok)
or
(c) Or is the whole DKIM concept intrinsically broken?