DKIM body hash did not verify with WHMCS issue

[ravivgolov]

Hello

I have enabled DKIM, and it's working perfectly. It only fails when used with one system: WHMCS.
The DKIM working and verified everywhere I am using the SMTP(Example: DirectAdmin, PHP, SWAKS).
I tested another SMTP software(haraka) with the same WHMCS system and the DKIM passed.

What can be the reason? I am not altering anything, default installation - just added one header to the message:headers and enabled limit rate and zone loop.

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=neutral (body hash did not verify) [email protected] header.s=defaultga header.b=TrH3MEAs;
       spf=pass (google.com: domain of [email protected] designates 15.x.x.x as permitted sender) 

Please provide me with some ideas on how to debug this issue, why the message is being altered, and how WHMCS is involved after ZoneMTA accepts the message.

Thank you.

[JQuags]

I have a similar report, not with WHMCS though. Are you able to reproduce and get headers?

My report had

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
X-Mailer: WPMailSMTP/Mailer/smtp 4.1.1

Looked like the end of the message had a TAB / space however I am not able to reliably reproduce this in any way. Past report had an issue with new line \n so I suspect a similar character whmcs and wpsmtp mailer and the encoding is causing an issue.

[ravivgolov]

Unfortunately, either I...

If you find a fix please let me know too

[ravivgolov]

I have a similar report, not with WHMCS though. Are you able to reproduce and get headers?

My report had

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
X-Mailer: WPMailSMTP/Mailer/smtp 4.1.1

Looked like the end of the message had a TAB / space however I am not able to reliably reproduce this in any way. Past report had an issue with new line \n so I suspect a similar character whmcs and wpsmtp mailer and the encoding is causing an issue.

But I don't understand. If WHMCS initiates the SMTP connection, can it alter the body after the message is signed by ZoneMTA?

Also, I don’t understand how to fix this. What is your solution for the previous issue with the newline? How were you able to fix it?

[JQuags]

The new line was a previous bug report in dkim signing now resolved where \n was not handled properly. The issue is likely content of the email itself, or a combination of the content/mime and something in the message. Does it look like there is a tab at the end of the email message in your dkim failure? Maybe a line with one tab spacing after the final html tag?

[ravivgolov]

Well, where should I check? I have the email source, but I still don't understand how that happens after the email is signed with DKIM. And for one system(WHMCS), the DKIM signature happens last...

And how do you fix this new line? on WHMCS or on ZoneMTA? I am a bit confused... since the DKIM signing happened last.

[ravivgolov]

@JQuags How to debug this? I don't understand how this works if I sign DKIM with Zonemta, how is WHMCS able to manipulate the email after I sign it and send it?

Thank you

[ravivgolov]

@JQuags @louis-lau So weird, when I use DirectAdmin connected to my SMTP, and I connect the SMTP from DirectAdmin
Everything is good, both from zonemta and directadmin:
dkim=pass [email protected] header.s=mdkim header.b=CF9aXSqx;
dkim=pass [email protected] header.s=x header.b=Zu+yOsMu;

But when I connect the SMTP directly to WHMCS from zonemta without directadmin in the middle, it fails with body hash.
Really does not make sense, I have no clue.

If you have any ideas - please let me know, I am out of ideas.

[louis-lau]

The only thing that makes sense is that the specific body is triggering a bug in zone-mta. That's also what @JQuags already said if you read carefully. Nobody said whmcs is modifying the body after signing.

If you can reproduce the bug, you can fix it. If you can't fix it, make sure we can reproduce it (by actually giving an example payload that doesn't get signed), and maybe someone wants to take a look for you.

Without it being reproducible by us, every answer is a complete stab in the dark.

[ravivgolov]

What should I provide to try troubleshooting the issue?

I don't know how to troubleshooting this issus with zonenta yet.

When you mean by payload that can't be signed you mean to provide the the raw html, for an example from Google inbox? I send email from whmcs to Google and there I see the body hash breaks.

Thank you

[ravivgolov]

Is there anything here that can do the bug?

Date: Mon, 16 Sep 2024 20:52:33 +0000
To: Raviv Golov <[email protected]>
From: SuppRessed LLC <[email protected]>
Reply-To: SuppRessed LLC <[email protected]>
Subject: Unsubscribe Confirmation
Message-ID: <[email protected]>
X-Mailer: SuppRessed LLC
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_jJy1XINW8kw7lrQWFcK7Ni0B0Msz8dL5oGvGuTkoA"

This is a multi-part message in MIME format.

--b1_jJy1XINW8kw7lrQWFcK7Ni0B0Msz8dL5oGvGuTkoA
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


<<HTML....>>


--b1_jJy1XINW8kw7lrQWFcK7Ni0B0Msz8dL5oGvGuTkoA--

The next is just the HTML

[ravivgolov]

I have this also:

Breaks either:

X-Zone-Loop: f1606b3c2dfb26af699bb450c4d92aceb0849584a36c
domain-dkim: test.com
X-mta-pool: transactional-3
Feedback-ID: 191ff46c671000eef1:t:mw:mailwish
X-EBS: https://test.com/lists/block-address
X-complaint-id: 191ff46c671000eef1
X-complaints-to: [email protected]
X-Abuse: <mailto:[email protected]>
X-MailWish-Tracking-ID: 191ff46c671000eef1
X-Originating-IP: [x.x.x.x]
Date: Tue, 17 Sep 2024 09:18:32 +0000
To: Raviv Golov <[email protected]>
From: test LLC <[email protected]>
Reply-To: test LLC <[email protected]>
Subject: Welcome
Message-ID: <[email protected]>
X-Mailer: test LLC
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_D95nLz99moAKDPEuw59jAUmuUxtk3rIfDSbmjtiZvc"
Content-Transfer-Encoding: 8bit
X-Zone-Spam-Resolution: no action
X-Zone-Spam-Status: No, score=-42.74, required=14, tests=[FREEMAIL_ENVRCPT=0, FROM_HAS_DN=0, FROM_EQ_ENVFROM=0, MANY_INVISIBLE_PARTS=0.05, WHITELISTED_DOMAIN_MANY_SPAM_NOTSPAM=-40, HAS_PHPMAILER_SIG=0, WHITELISTED_DOMAIN=-3, TO_DN_ALL=0, XM_UA_NO_VERSION=0.01, MB_SUBJECT_USED_IN_SPAM=2, MIME_GOOD=-0.1, MID_RHS_MATCH_FROMTLD=0, DBL_BLOCKED_OPENRESOLVER=0, FREEMAIL_TO=0, RCVD_COUNT_ZERO=0, BAYES_HAM=-3, URI_COUNT_ODD=1, AUTOGEN_PHP_SPAMMY=1.5, GPT_HAM=-1.2, ARC_NA=0, ASN=0, MIME_TRACE=0, RCPT_COUNT_ONE=0, HAS_REPLYTO=0, REPLYTO_EQ_FROM=0]

--b1_D95nLz99moAKDPEuw59jAUmuUxtk3rIfDSbmjtiZvc
Content-Type: text/plain; charset=us-ascii

Could be this?
Content-Type: text/plain; charset=us-ascii

[ravivgolov]

@louis-lau I think I found the problem, it is that Content-Type: text/plain; charset=us-ascii
What can I do to fix this? for some reason, when I sending via zonemta directly it change the to Content-Type: text/plain; charset=us-ascii while excepting utf8 in the dkim and content encoding 8bit, when connecting to Exim mta, the content type is correct: Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Why zonemta changing the content type to ascii? and Exim not?

[ravivgolov]

@louis-lau @JQuags
I clearly found the issue, when the settings in WHMCS are set to 8bit or 7bit body hash break.
When using base64 - works.
Quoted-printable also fails.

I don't know why WHMCS set asci type for Mail Encoding type 7bit and 8bit.
However, the bug occurs when the asci content type is in ZoneMTA.

This is the case Content-Type: text/plain; charset=us-ascii
And the content is in utf8, not sure if this is zonemta or whmcs bug. but switching to Base64 in whmcs resolves this.

If anyone here wants to fix it - that would be good.

Example fail:

--b1_zOWYckxpnq6Tjok2PdfQ6MUNoM7NkBVlaRTNY3fUk4
Content-Type: text/plain; charset=us-ascii

Dear Raviv Golov, 

We have received your order and will be processing it shortly. The details of the order are below: 

Order Number: 


5555555

You will receive an email from us shortly once your account has been setup. Please quote your order reference number if you wish to contact us about this order. 

[JQuags]

I can reproduce this with php + html email and a tab on it. The email end looks like

/html>\r\n\t\t\r\n

when I take the basics from dkim-relaxed-test.js and run it through nodeunit. A tab anywhere else except at the bottom causes no issues. I couldn't reproduce it in thunderbird. When I find an acceptable fix I will post a PR.

[GioPan04]

I'm having the same issue. The mail is rendered by Symfony Mailer. I noticed that if I don't use inky_to_html filter on the email template zone-mta correctly sign the message.
In contrast to @JQuags my emails doesn't contains any \t anywere.

[ravivgolov]

Guess we need a major update about this. Probably many more cases cause the same.
Something in the core is wrong. With haraka I don't face it.

[JQuags]

I'm having the same issue. The mail is rendered by Symfony Mailer. I noticed that if I don't use inky_to_html filter on the email template zone-mta correctly sign the message. In contrast to @JQuags my emails doesn't contains any \t anywere.

Any chance you can look and see if there is a tab at the bottom line of the email. The \r\n\t\t\r\n is after the email has been processed via https://github.com/zone-eu/zone-mta/blob/master/lib/dkim-relaxed-body.js. I can place tabs anywhere and get a valid has except on the last line.

[GioPan04]

@JQuags sorry for the late response. How are you validating the presence of tabs? Are you inspecting the output of some function or the contents of a received email?