On 09.11.2014 00:35, Phillip Carroll wrote:
[...]
> 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:
I'm curious how you know that those were valid signatures and no changes
took place in transit?
Some other big sources of email like paypay, facebook, linkedin or gmail
definitely know how to do DKIM, so you might check whether you get valid
DKIM from those sources. It shouldn't be hard to send a test-message
from gmail to your server if you don't see such traffic anyway. Having
your bank send a test-message to gmail, so you can check their setup is
not the culprit is certainly harder.
>
> [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).
It might be like this: the first Chase server adds the DKIM-Signature,
the last one appends a disclaimer like "This message is intended for the
indended recipient only..." and thus breaks the signature. Just a wild
guess.
>
> 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.
But according to
"h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding"
those additional headers are safe.
> 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.
I'm sure that those added headers are no issue. They are not considered
by DKIM for signing. However, I'm lacking experience regarding
"MIME-Version:Content-Type:Content-Transfer-Encoding" which are included
in the signature. Some transformation like re-encoding of attachments is
possible, though I wouldn't expect it by exim.
>
> 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".
The mailing list is modifying the body by adding a footer, thus
invalidating a signature. Thats not an exim-issue but related to the
mailinglist software or configuration. I'd probably prefer Sympa to
mailman, but that's an unrelated issue.
>
> Basically, I am asking:
>
> (a) Is the exim dkim support simply broken in this regard?
no
> 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)
Possible, but unlikely.
> or
> (c) Or is the whole DKIM concept intrinsically broken?
Let's not get philosophical. ;)
--
Karlsruher Institut für Technologie (KIT)
Steinbuch Centre for Computing (SCC)
Patrick von der Hagen
Zirkel 2, Gebäude 20.21, Raum 005.1
76131 Karlsruhe
Telefon: +49 721 608-46433
E-Mail: hagen@???
Web:
http://www.scc.kit.edu
KIT - Universität des Landes Baden-Württemberg und
nationales Forschungszentrum in der Helmholtz-Gemeinschaft
