DKIM+disclaimer problems after upgrade to mail2 module

Getting problems sending emails after recent upgrade to mail2 module.
Basically bh mismatch.

From google:
dkim=pass header.s=default header.b=Wbs71WXd;
dkim=neutral (body hash did not verify) header.s=default header.b=nLwoytM1;
spf=pass ( domain of my@email designates my.server as permitted sender)
From Apple
dkim=fail reason=“signature verification failed - bh mismatch” (2048-bit key) header.b=tPxZWAUb
checked the full header from email and “bh” is really change in the dkim signatures

Received: by (Postfix, from userid 8) id E550C208DD; Thu, 31 May 2018 07:36:06 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.11.0 E550C208DD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1527748566; bh=beRap2eoZuEb8ciAESGhJaal9eWCBg/3W2dHE9udVAU=; h=From:Subject:Date:To:From; b=Wbs71WXdhDSbfpNUDeDuhcTts/lx+kJfQP0z/Y/vSNbxMLNI8aWtz5jBZ82Hv+nD5
Received: from imac.zimni.local (unknown []) (Authenticated sender: my@email) by (Postfix) with ESMTPSA id C70512059F for <my@email>; Thu, 31 May 2018 07:36:02 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.11.0 C70512059F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1527748566; bh=aBsw2RCt5lM5IM7zsMTPk8YIwk4r8WpbCQo8+trKgAc=; h=From:Subject:Date:To:From; b=nLwoytM1PwA1ofAhgY5X1O8iYON7rSjGBTs32AvRbyoLFZyLzzLgDuxUXRE/wuf2H

I think this is done by Rspamd av engine is filtering outgoing emails or by “Append a legal note to sent messages”.
Any ideas would help.

So done more tests and can confirm that this behavior is due "Append a legal note to sent messages”.
I’m considering like a bug because is creating dkim authentication issues.

1 Like

The disclaimer feature should not be used any more, as explained here

Having said that a broken signature can considered a #bug. Let me see if I can reproduce it, thank you!

Added card here

Thank you for quick advise.
So is this mean that we will no longer have this functionality in email module?
That was very handy future.
I don’t think so others will be happy visiting all their customers to add disclaimer to their mail client app.

1 Like

Such configuration must be moved to client.
WebTop already supports it:

I think something similar is possible with many other mail clients.

This means that alterMIME is no longer maintained and could be removed by upstream in the next major release. I don’t know another project that does the same thing… What to do?

I think the best thing to do is being prepared to find an alternative and planning the migration to it.

Not sure why you mean “must” be on the client mail app.
Then if you host several domains on NS you need to do it manually on every client machine by editing signatures.
This future was great for quick adding disclaimer for all domain users at one time.
Some of my clients are far away from my company, some of them are not computer gigs and probably don’t know how to edit settings in their mail apps.
Looks like only one solution for my company is to downgrade to previous ver of mail module.
Very sad :worried:

1 Like

@zimny: it’s a lost battle…


@saitobenkei is right, it’s a long and old discussion :smiley:
Just search the forum for other threads.

Let’s see if @stephdl or @davidep can find a fix next days :wink:


Isn’t necessary.

I’m the first who has fought to have disclaimers/signatures managed directly by the server and not by the clients.

I would like you share the full email header in a cool way to read it, pastebin or full email and the signature you added please.
For what I have tested with a really basic signature, rspamd doesn’t break altermime/opendkim and the signature was added.

I checked with the webmail sogo, how did you test it ?


@davidep something fun, when I sign email by PGP (like all of my sent emails with thunderbird) the ALTERMIME signature is not added.

If the email is not signed, then the signature is added.

I can see each time the

May 31 21:38:27 prometheus postfix/pipe[31578]: 2D7AA1806B0DC: to=<>, relay=dfilt, delay=1.3, delays=1.2/0.01/0/0.11, dsn=2.0.0, status=sent (delivered via dfilt service)

Fun, but at the end I could understand why, the message could not be modified, maybe a bit of documentation should be done ???

1 Like

I have tested in very simple way. Send emails to google and icloud with and without added "Append a legal note to sent messages” to the domain. When "Append a legal note to sent messages” future was on got from both providers “signature verification failed - bh mismatch” dkim errors. When i turned off "Append a legal note to sent messages” in email->domain preferences both providers rapport no errors.

Here is my appended signature

“IT Pro Systems” - E-MAIL DISCLAIMER - This message is for the intended recipient only and may contain confidential or proprietary information. If you receive this message in error, please immediately delete it, destroy all copies of it and notify the sender. If you contact us by E-mail, we may store your details to aid communication. We may also monitor mail entering and leaving from “IT Pro Systems”. We take reasonable precautions to ensure that our E-mails are virus free. However, we cannot accept responsibility for any virus transmitted in net and recommend that you subject any incoming E-mail to your own virus checking procedures.

tested for (office365) with your signature, it works as expected

Received: from
 (2a01:111:f400:7e06::202) by
 (2603:10a6:20b::44) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.797.11 via Frontend
 Transport; Fri, 1 Jun 2018 15:19:18 +0000
Authentication-Results: spf=pass (sender IP is;; dkim=pass (signature was
 verified);; dmarc=pass action=none;
Received-SPF: Pass ( domain of
 designates as permitted sender); client-ip=;;

tested from google, with your signature it works as expected

Received: from ( [])
        by with ESMTPS id f56-v6si452943qtk.355.2018.
        for <>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 01 Jun 2018 08:19:18 -0700 (PDT)
Received-SPF: pass ( domain of designates as permitted sender) client-ip=;
       dkim=pass header.s=default header.b=fZ2KlyKj;
       dkim=neutral (body hash did not verify) header.s=default header.b=TZCBe+JQ;
       spf=pass ( domain of designates as permitted sender);
       dmarc=pass (p=NONE sp=NONE dis=NONE)

can you send me your private apple email (by PM) I will send you an email, can you transmit it back please ?

For what I saw, either a bug to find on your side, or something misconfigured somewhere…or probably apple s… :smiley:

It seems that Google is aware that the body hash is not valid. Maybe Apple checks are more strict.

Can we disable the body signing if alterMime is enabled?

I think we have a bit misunderstanding here.
In your google header you have exactly the same problem “dkim=neutral (body hash did not verify)” / apple is a bit more restrictive and they notice this issue "dkim=fail reason="signature verification failed - bh mismatch"
They will allow email anyway because second dkim record is correct.
Problem is when you are dealing with the company who has more restrict dmarc policy.
Then they will reject email from you.

Our misunderstanding is between NS appended disclaimer and dkim signature meaning.

My first thoughts was outgoing emails are scanned by rspamd and this is dealing with body hash issue.
But when I have turn off disclaimer on NS then dkim signatures pass without any notices or fail messages from providers.
I think David has some solution for it.

Yep we do not see it before, but sure the former nethserver-mail is impacted too. It makes sense, if you add a signature you modify the body

Not sure…maybe one way, however we could try to add the disclaimer before to sign

1 Like

this has been searched a lot on several forum, but without much answers.

We use a postfix filter to add a disclaimer, but the MILTER (rspamd, opendkim) are processed first, then the dfilt filter proceed to add the disclaimer at the end of the process, and of course the body mismatch the dkim signature.
One way could be to add the diclaimer in the header, not tested yet.