DKIM check fails for mails sent with AquaMail

[shamrock]

Hello,

I've noticed that my mails sent with AquaMail don't pass the DKIM check most of the time. The mail header at the receiver's end shows "dkim=neutral (body hash did not verify)" so it looks as if the mail has been altered after sending.

This does not happen if I send mails from the same account with Outlook, Thunderbird or webmail.

Any idea what could cause this?

[shamrock]

I send my mails through smtp.zoho.com.

[Kostya Vasilyev]

DKIM signing is done by the outgoing server, not AquaMail.

DKIM validation is done by your incoming server, not AquaMail (the app just looks for the defacto standard Authentication-Results header).

Maybe you could "view headers" on the message (on the receiving side) and post the actual Authentication-Results header.

[shamrock]

Hello Kostya,

I did some further research and found out that it is likely to have to do with the encoding of German Umlaut characters. When there are no special characters in the mail, the problem does not occur.

I'll email you some test results so you can have a look at it.

[Kostya Vasilyev]

AquaMail encodes "umlaut" characters using Windows-1251 or UTF-8 (it depends on what is actually necessary).

[Kostya Vasilyev]

Just tried a message with Umlauts, from AquaMail, a Gmail account, to check-auth@verifier.port25.com.

Came back with DKIM: pass.

Since DKIM signing is handled by the SMTP server, this looks to be a Zoho issue.

[StR]

There could be a difference (between a message sent from Aquamail and from Thunderbird/Outlook) stemming from how the message is sent: multipart vs text/plain.
This, in turn, may depend on whether the format of the outgoing message is set differently: plain text vs rich text in Aquamail, and plain text vs HTML (HTML/text combination) in Thunderbird.

If the message is sent as multipart, than the body should not be modified by the server. If the message is sent as text/plain, the body could be modified by the SMTP server if it contains 8-bit symbols (which a symbol with the umlaut is ). (It is not the best behavior, and an atavism, but I've seen some servers doing that.) If that modification is done after DKIM signing, that could lead to the difference. (And I believe that can happen also on the receiving side if they have outdated server configuration.)

It is still the server's issue, but I am just thinking of the reason why the behavior could be different between different mail programs.

[Kostya Vasilyev]

Could also have something to do with encoding type.

Aqua sends messages like this:

Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

Ă ğ č ö


Why no encoding to Quoted-Printable or base64?

https://cr.yp.to/smtp/8bitmime.html

As far as I know, all servers can handle 8-bit messages.

( and I think DJB knows what he's talking about )

It also keeps messages readable (a big plus for certain users):

https://code.google.com/p/android/issues/detail?id=63409

( the bug report is about something else, but it does mention base64-encoding the text parts as undesirable )

[StR]

Kostya:
Yep, that's exactly what I meant. I just didn't want to go all that deep in the technicalities.
My servers (and clients) had been set to use 8-bit transmission for many years.

I had seen (I believe not on my server) 8-bit messages that were corrupted because they were not configured correctly (i.e. missing the 8-bit and charset headers), but that was in mid-90s. In most cases the 8th bit was stripped.

[Kostya Vasilyev]

Well, if using 8-bit had ever been an issue for *actual mail transmission* -- I'd have heard about it by now (although I now think there might have been one such case, just not explained well enough by the user).

Other than that, assuming 8-bit clean SMTP has been just fine all this time.

But there could be a bug in Zoho's DKIM code

---

I have DKIM signing enabled on the aqua-mail.com mail server, which sends this forum's notification emails. This is postfix + opendkim.

Just tried sending a test message from that machine using command line "mail", with Russian characters (also requiring 8 bits).

According to Gmail, the DKIM signature was just fine, even though this message, too, was sent as 8-bit text without quoted-printable or base64.

Received: from mail.aqua-mail.com (aqua-mail.com. [176.58.105.125])
        by mx.google.com with ESMTPS id j199si1868370wmj.84.2016.03.29.15.38.03
        for <...@gmail.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 29 Mar 2016 15:38:03 -0700 (PDT)
Received-SPF: pass (google.com: domain of ...@aqua-mail.com designates 176.58.105.125 as permitted sender) client-ip=176.58.105.125;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@aqua-mail.com;
       spf=pass (google.com: domain of ...@aqua-mail.com designates 176.58.105.125 as permitted sender) smtp.mailfrom=...@aqua-mail.com
Received: by mail.aqua-mail.com (Postfix, from userid 0)
   id 13534100BE; Wed, 30 Mar 2016 01:38:03 +0300 (MSK)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aqua-mail.com;
   s=outgoing; t=1459291083;
   bh=meOQOQU/44CzEVWy0So3PuNHfUYIXSGb0R1xhHLOr1E=;
   h=Date:To:Subject:From:From;
   b=mg4n6p2WpoUupQb4TGM7bI1OR7j3EInRYo+/qJu0Bwsrzs1IWgZ4LNh7lCpjLQoNl
    DtBfJLf4M6agTabAzXsty1xcs/BcOMkpQq6qKheH19MVPOHSQW+I/hCJC04CjbHixz
    2xV0KyC4NNo64g+2nlDFJKYQPwQSKdDFaci9cGwY=
Date: Wed, 30 Mar 2016 01:38:03 +0300
To: ...@gmail.com
Subject: =?utf-8?B?0J/RgNC+0LLQtdGA0LrQsCDQvdCwINC00L7RgNC+0LPQsNGF?=
User-Agent: Heirloom mailx 12.5 6/20/10
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Message-Id: <20160329223803.13534100BE@mail.aqua-mail.com>
From: ...@aqua-mail.com (root)

Текстовое письмо

[StR]

Just in case: I didn't imply that one should do Q-P for plain text at any level. Not at all.
Nor that I implied an 8-bit message shouldn't be sent as plain text.
But if one of the servers in the chain: SMTP.zoho.com -> (possibly outgoing.zoho.com) -> SMTP.recipient.com (-> InternalSMTP.recipient.com)  does a conversion, that can lead to the DKIM breaking. And that's server's fault, imho.

In all of this, I am just thinking about a scenario that would explain why the OP might see the difference between messages originating from different mail clients.
But, there could be some conflict between the DKIM implementation and the message content as well.

I did a quick search and found a couple of discussions how the content of the message can result in the DKIM check breaking. Maybe this would provide some useful ideas:
1. Here is the likely cause is the line that is too long (exceeds 988 characters):
see the 2nd from the bottom response:
https://sourceforge.net/p/dkim-milter/mailman/message/24479770/

2. There is discussion here with some ideas, although without a clear answer:
http://stackoverflow.com/questions/25918934/dkim-fails-body-hash-when-signing-at-mta-using-opendkim

[Kostya Vasilyev]

Yes, you're right, it could be an SMTP rewrite somewhere along the way.

We can however narrow it down to the sending "half" of the process (excluding the receiving "half") -- this user did his testing via:

https://www.port25.com/support/authentication-center/email-verification/

[shamrock]

Zoho has confirmed today that this is a bug on their end and that they're going to fix it in the near future.

[StR]

Great!
Thanks for reporting back!