DKIM+disclaimer problems after upgrade to mail2 module

testing
mail2
mailserver

(Zimny) #1

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

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

Received: by gb.itprosystems.ltd (Postfix, from userid 8) id E550C208DD; Thu, 31 May 2018 07:36:06 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.11.0 gb.itprosystems.ltd E550C208DD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itprosystems.info; s=default; t=1527748566; bh=beRap2eoZuEb8ciAESGhJaal9eWCBg/3W2dHE9udVAU=; h=From:Subject:Date:To:From; b=Wbs71WXdhDSbfpNUDeDuhcTts/lx+kJfQP0z/Y/vSNbxMLNI8aWtz5jBZ82Hv+nD5
	 3eorGxiHoYP92hlXTU2DjVzbvqDemoZZD79uMTG1Tbli9y5E0+4DWIfTFrpj4z4Fuh
	 Io9N8fDP4QtlcgK21wak5nLXQw9fvcBfdwTXYLDtnvMJRmxO5zs1/ZbqeR4p7wFt/U
	 k/xZlU6/llYqP48Ru7npLqjVVvBgargHRJGqBJuVU1VEmSZjWT6pUboAaSwapE4K9s
	 4LIpjsFV/6NkZdrsZAXV/x5IKZukwrz18pOuwIPDqQCNDLT/Z8jlZzzO5anpBo0OWh
	 HPVu7pkK6gQxg==
Received: from imac.zimni.local (unknown [192.168.0.12]) (Authenticated sender: my@email) by gb.itprosystems.ltd (Postfix) with ESMTPSA id C70512059F for <my@email>; Thu, 31 May 2018 07:36:02 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.11.0 gb.itprosystems.ltd C70512059F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itprosystems.info; s=default; t=1527748566; bh=aBsw2RCt5lM5IM7zsMTPk8YIwk4r8WpbCQo8+trKgAc=; h=From:Subject:Date:To:From; b=nLwoytM1PwA1ofAhgY5X1O8iYON7rSjGBTs32AvRbyoLFZyLzzLgDuxUXRE/wuf2H
	 aoqlJsd+V/vdUno+PgLFbtm6AVFGlTJI45Xuu+uuykCqIcKKbh1pv2xgra8Etzy2RQ
	 JozjWxmdofWdR2Kroec+VmRabUxOEKduzgm2uhn8J4LGohaJHH/EfZIGpsxSt+MiEE
	 //NIn5dY4RalMm9svF4MpcPt/sT0ko84mbwlHFJ1SNBA1K3z/VJNFYkLDYJtwsnt0j
	 J8nzutbU8c2FWYPPvtrgyeTNsMFPDL6UAhGOqSz3XZ1DGAqtbCkb1AD44kWjqvbb6L
	 pQ8b9uBkKP/IA==

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.


(Zimny) #2

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.


(Davide Principi) #3

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

http://docs.nethserver.org/en/latest/mail2.html#append-a-legal-notice

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

Added card here https://github.com/orgs/NethServer/projects/1#card-10201339


(Zimny) #4

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.
:face_with_monocle:


(Giacomo Sanchietti) #5

Such configuration must be moved to client.
WebTop already supports it: http://docs.nethserver.org/en/v7/webtop5.html#mailcards-of-user-and-domain

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


(Davide Principi) #6

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.


(Zimny) #7

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:


(Saito Benkei) #8

@zimny: it’s a lost battle…


(Giacomo Sanchietti) #9

@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:


(Saito Benkei) #10

@giacomo

Isn’t necessary.

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


(Stéphane de Labrusse) #11

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 ?


(Stéphane de Labrusse) #12

@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=<stephane.delabrusse@gmail.com>, 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 ???


(Zimny) #13

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.


(Stéphane de Labrusse) #14

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

Received: from VE1EUR02FT022.eop-EUR02.prod.protection.outlook.com
 (2a01:111:f400:7e06::202) by AM6PR03CA0031.outlook.office365.com
 (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 164.132.77.216)
 smtp.mailfrom=de-labrusse.fr; chubbfrance.com; dkim=pass (signature was
 verified) header.d=de-labrusse.fr;chubbfrance.com; dmarc=pass action=none
 header.from=de-labrusse.fr;
Received-SPF: Pass (protection.outlook.com: domain of de-labrusse.fr
 designates 164.132.77.216 as permitted sender)
 receiver=protection.outlook.com; client-ip=164.132.77.216;
 helo=prometheus.de-labrusse.fr;

tested from google, with your signature it works as expected

Received: from prometheus.de-labrusse.fr (prometheus.de-labrusse.fr. [164.132.77.216])
        by mx.google.com with ESMTPS id f56-v6si452943qtk.355.2018.06.01.08.19.18
        for <stephane.delabrusse@gmail.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 01 Jun 2018 08:19:18 -0700 (PDT)
Received-SPF: pass (google.com: domain of stephane@de-labrusse.fr designates 164.132.77.216 as permitted sender) client-ip=164.132.77.216;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@de-labrusse.fr header.s=default header.b=fZ2KlyKj;
       dkim=neutral (body hash did not verify) header.i=@de-labrusse.fr header.s=default header.b=TZCBe+JQ;
       spf=pass (google.com: domain of stephane@de-labrusse.fr designates 164.132.77.216 as permitted sender) smtp.mailfrom=stephane@de-labrusse.fr;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=de-labrusse.fr

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:


(Davide Principi) #15

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?


(Zimny) #16

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.


(Zimny) #17

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.


(Stéphane de Labrusse) #18

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


(Stéphane de Labrusse) #19

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


(Stéphane de Labrusse) #20

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.