I'm using OpenDKIM for verifying signed mails that are incoming to my mail server and use it as a spam addon (if dkim is broken, mail lands in Junk). However, I'm getting lot of false-positives with broken DKIM (signature verification failed), for which main cause is mailing lists software, which adds its own headers/modify content etc.

I'm wondering is there any built-in feature in OpenDKIM (like whitelist) that will allow me to decrease false-positives, since it is not possible to contact every admin of every mailing list and say they have a improper setup that breaks DKIM.

Example header below:

Return-Path: <ubuntu-translators-bounces@lists.ubuntu.com>
Delivered-To: receiver@example.com
Received: from localhost (localhost [])
    by example.com (Postfix) with ESMTP id 6AEAD20DC
    for <receiver@example.com>; Sat, 12 Oct 2013 23:51:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at qhost.pl
Received: from example.com ([])
    by localhost (example.com []) (amavisd-new, port 10024)
    with LMTP id Ly8eSJhPPnln for <receiver@example.com>;
    Sat, 12 Oct 2013 23:51:04 +0200 (CEST)
Received: from huckleberry.canonical.com (huckleberry.canonical.com [])
    by example.com (Postfix) with ESMTP id 1B86E20DB
    for <receiver@example.com>; Sat, 12 Oct 2013 23:51:04 +0200 (CEST)
Authentication-Results: example.com;
    dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=qOy78FPq;
    dkim-adsp=none (unprotected policy)
Received: from localhost ([] helo=huckleberry.canonical.com)
    by huckleberry.canonical.com with esmtp (Exim 4.76)
    (envelope-from <ubuntu-translators-bounces@lists.ubuntu.com>)
    id 1VV754-0003E4-AB; Sat, 12 Oct 2013 21:50:38 +0000
Received: from mail-pd0-f182.google.com ([])
 by huckleberry.canonical.com with esmtp (Exim 4.76)
 (envelope-from <geochr22@gmail.com>) id 1VV74z-0003Dp-8S
 for ubuntu-translators@lists.ubuntu.com; Sat, 12 Oct 2013 21:50:33 +0000
Received: by mail-pd0-f182.google.com with SMTP id r10so5800218pdi.13
 for <ubuntu-translators@lists.ubuntu.com>;
 Sat, 12 Oct 2013 14:50:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
MIME-Version: 1.0
X-Received: by with SMTP id pj2mr29160511pac.62.1381614632237;
 Sat, 12 Oct 2013 14:50:32 -0700 (PDT)
Received: by with HTTP; Sat, 12 Oct 2013 14:50:32 -0700 (PDT)
In-Reply-To: <CAKnT5bMdetLwWU1Q4RQ_NdKDLDUgq8H0zRNawXs8rWNiXW0nVw@mail.gmail.com>
References: <CADFCDMTBhMxn+e4OJvZD7QN1joYrhCR3-CgH2weEhOSu36UkrQ@mail.gmail.com>
Date: Sun, 13 Oct 2013 00:50:32 +0300
Message-ID: <CAHyzMMutO3_4wKNT-G3=-m+bHQTiqoT74OWBNis=kMRXAPWfSg@mail.gmail.com>
Subject: Re: nothing here
From: nobody <nobody@gmail.com>
To: nobody <nobody@ubuntu.com>
Cc: "Translators, Ubuntu" <ubuntu-translators@lists.ubuntu.com>
X-BeenThere: ubuntu-translators@lists.ubuntu.com
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion about translating Ubuntu
List-Unsubscribe: <https://lists.ubuntu.com/mailman/options/ubuntu-translators>, 
List-Archive: <https://lists.ubuntu.com/archives/ubuntu-translators>
List-Post: <mailto:ubuntu-translators@lists.ubuntu.com>
List-Help: <mailto:ubuntu-translators-request@lists.ubuntu.com?subject=help>
List-Subscribe: <https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators>, 
Content-Type: multipart/mixed; boundary="===============1762773400059964515=="
Errors-To: ubuntu-translators-bounces@lists.ubuntu.com
Sender: ubuntu-translators-bounces@lists.ubuntu.com

I modified above message (removed IP's and logins), so it might indeed have a broken DKIM, but originally it was untouched - only by mailing list sofware @ ubuntu.com

So again, is there a way to set up OpenDKIM to be more tolerant/ignore/verify in different way the DKIM signature for such mail?


There is a standard mechanism for making DKIM verification more tolerant of format modification such as by filters or relays, but it has to be done at the sending end rather than receiving, and all it does is become more tolerant of things like changes in whitespace rather than changes to the actual message. Basically you can choose between a relaxed (more tolerant) and simple (more strict) mode for both the headers and body when signing, and the verifying system later will use the appropriate mode in order to verify successfully. This can't be modified at the receiving end because it's impossible to know what the signature would have been with a different processing mode.

The signing system at the sender chooses which headers to include or exclude from the signature, so if you know that a relay or list is going to modify or remove a header, the sender should exclude that from verification.

However, given that a mailing list will usually change the message and headers, including important headers like Subject, the DKIM header from the original sender should fail verification.

Ideally, the mailing list software would be DKIM-aware and it would strip out the old DKIM header and replace it with one of its own, changing the From header accordingly, effectively now taking responsibility for the message rather than the original sender.

In the absence of this, if you are on the receiving end all you can do is whitelist particular servers.

This is a chicken and egg scenario with DKIM adoption: very few people enforce DKIM mismatches at the receiving end because it would have false positives, but this slows adoption of DKIM because there's little pressure for parties like mailing list hosts, etc, to fix these problems. Right now, if you strictly enforce DKIM mismatches at the receiving end you're still a bit of a guinea pig, even though DKIM has been in existence for years now. It seems more common for mail hosts just to use a DKIM mismatch as a factor contributing to their spam detection, which IMO is bad for DKIM adoption but I understand the chicken and egg problem behind it.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.