Join Log in
Score:1
avatar Server

Exim false negative on DKIM verification

cn flag
artfulrobot

My mailserver using exim4 has an ACL to check DKIM signatures. It accepts everything but it logs failures and writes a header with the results.

I'm sending mail from another server which I believe is adding DKIM sigatures correctly. (e.g. I've sent mail to gmail and outlook addresses, inspected the headers and both those systems have given the DKIM a pass.) But my mailserver is saying bodyhash_mismatch.

My mailserver doesn't always say DKIM is a fail.

Here's an email. I've changed the domains:

  • example.org This is the main organisation's domain; it's used in the From: header and it's the signer domain.T he public key is published in the DNS.
  • sender.example.org This is the server that sends the email, creates the DKIM header. It's the Return-Path header.
  • receiver.example.org This is my mailserver's domain, where the DKIM is being verified. This is where the X-dkim-check header is being added, and the text following domain= comes from $dkim_cur_signer
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from mail.receiver.example.org
    by mail.receiver.example.org with LMTP
    id t8rHGepc52SOVA8ADCPZSA
    (envelope-from <[email protected]>)
    for <[email protected]>; Thu, 24 Aug 2023 14:36:42 +0100
Received: from sender-rdns.example.org ([1.2.3.4] helo=sender.example.org)
    by mail.receiver.example.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    (Exim 4.94.2)
    (envelope-from <[email protected]>)
    id 1qZAVv-004DMU-00
    for [email protected]; Thu, 24 Aug 2023 14:36:42 +0100
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
    d=example.org; s=220151210; h=Sender:Message-Id:Subject:From:To:Date:
    Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
    Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
    :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
    List-Subscribe:List-Post:List-Owner:List-Archive;
    bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=; b=GTY2HZVje81tRJ0/xKFNUk5d7/
    9wE7CGtwmz2APM5VTDKY6q+qIbwhCRNzc6IWZ4j0Y9FOtnuVBeNR1I5xbOuqPaf62MYQZJFjLQ3/J
    PNpOpS3i1Yd3NCZUs1iB/Q8N+ii73FrvD5k1AA8F5yzJhVeaposgbkvU5vv1s/KgqTIA=;
Received: from localhost ([127.0.0.1] helo=sender.example.org)
    by sender.example.org with esmtp (Exim 4.96)
    (envelope-from <[email protected]>)
    id 1qZAVt-001EhO-2k
    for [email protected];
    Thu, 24 Aug 2023 14:36:41 +0100
Date: Thu, 24 Aug 2023 14:36:41 +0100
To: [email protected]
From: [email protected]
Subject: test Thu, 24 Aug 2023 14:36:41 +0100
Message-Id: <[email protected]>
X-Mailer: swaks v20201014.0 jetmore.org/john/code/swaks/
Sender: [email protected]
X-dkim-check: DKIM test failed: (domain=example.org), signature is bad.

This is a test mailing

How can I debug why exim on receiver.example.org thinks the signature is bad?

(I note that the DKIM signature includes a lot of headers that don't exist. Could that be a reason?)

EDIT: adding details:

  • Signing exim: 4.96-15+deb12u1.
  • Receiving exim: 4.94.2-7~bpo10+1
53
1 + 3
cn flag
artfulrobot
I've tried with/out Sender - makes no difference.
0
Reply
cn flag
artfulrobot
Thanks @anx : Signing exim: `4.96-15+deb12u1`. Receiving exim: `4.94.2-7~bpo10+1`
1
Reply
anx avatar
fr flag
anx
I downloaded `4.94.2-7~bpo10+1` from Debian/buster-backports and it *does not* (unsurprisingly, as built before Aug 2021) include the command-after-last-chunk fix without which the body hash would be incorrectly calculated with some non-message protocol data. Updated answer accordingly.
0
Reply
Score:1
anx avatar Server
fr flag
anx

I don't think the "is bad" message expresses any particular reason for why a signature could not be validated. Configure proper Authentication-Results headers: that relay everything exim is telling you via $dkim_verify_reason.

Try to pinpoint which messages are failing, I remember examples of other verifiers bugging out only on certain message or message part sizes (block-aligned, <=16KiB, >=16MiB.. your test message looks small) or line length (your test message looks neatly, albeit unusually, folded).

Also, compare the message source as it was sent (ideally, as it was uploaded separately to the Sent mailbox). It may have had some syntax problem that has been discarded on receipt, but had been significant for the signature.

Ideas:

  • I see a trailing semicolon in the signature, and no fold before the final b= tag, that is somewhat uncommon - less tested, and possibly not how the message looked when it was signed.
  • I also see a modern TLS version used with an ancient exim version ("All versions of Exim previous to version 4.96 are now obsolete."). I wonder if you are using your distributors build that is missing relevant fixes already applied upstream.

I suspect the latter is causing your problem, based on this patch not being applied by Debian oldstable so far. If so, it should primarily affect small messages transmitted via BDAT over TLS.

  1. Update to more recent release of exim - possibly necessitating a Debian upgrade, as you are already on backports - or
  2. Read or file Debian bug reports, the missing fix (link goes to cherry-picked version ready to be applied on 4.94.2) I suspect at fault may be judged worthy of pulling, if indeed at fault here - or
  3. disable chunking support (RFC 3030) altogether, if that is okay for your use case - empty chunking_advertise_hosts = will not announce BDAT availability to anyone, that should do the trick - at potentially significant performance cost for large messages.
+ 2
cn flag
artfulrobot
`bodyhash_mismatch` is the output of `$dkim_verify_reason` but I will add others into the log line and check.
1
Reply
cn flag
artfulrobot
Wow, thanks for such an amazingly in-depth answer! Really appreciate it. I upgraded Debian and now it's working. thanks!
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.