Home / server / Questions / 1142318
Accepted
artfulrobot
Asked: 2023-08-24 22:01:07 +0800 CST

Exim false negative on DKIM verification

  • 772

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
exim

1 Answers

  1. Best Answer

    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.
    • 1