Jun 20, 2014 DKIM signing issue - body hash did not verify. It suggests something is getting added to the body after signing, but I can't see where that might be, nor can I spot something in the email body in the received email. Firstly, I should say I struggled a bit to. I'm using latest SmarterMail (12.5.5409) and after enabling DKIM for domain it looks like something is wrong with message hash. When I'm sending email to my private account at gmail.com I see in source/header 'body hash did not verify'.
I have successfully installed Postfix and OpenDkim on my server, and it's correctly signing mail from several different domains. The host we'll call webhost.example.com. It's running Ubuntu 18.04.2 LTS, Postfix 3.3.0 and OpenDKIM v2.11.0
Today I wanted to get output from some CRON jobs sent to my Gmail account so I set up the required entries in the KeyTable and SigningTable and generated the keys and tested it with a one line email to myself.
This should generate an email from [email protected]. It does, correctly signed by OpenDKIM, and delivered to my Gmail account where it successfully passes validation.
Here's what I get at GMail:
So far, so good.
I set up my cron jobs and add the line
The output is generated, signed and mailed, but GMail fails the DKIM validation with
Here's the complete email. If it's useful this is output from a curl request.
The emails from cron also fail the Port25 verifier in the same way
So, the question is:
Why does my DKIM configuration correctly sign everything but output from CRON?
What can I do to fix this?
I could try using a script to run the curl request and send the email with mail, but I have a number of other cron jobs to add yet and I'd rather fix the underlying problem before trying work-arounds.
Redd HerringRedd Herring
1 Answer
Since there was little response here I posted this question on ServerFault. Here's the answer I got, courtesy of cora. Setting the FixCRLF flag solved the problem. I haven't yet investigated the temporary files to see if there's more information to be had there.
The authentication results done by mx.google.com imply there's something different in the respecitve body between the messages you send on the command line and the ones which are send by a cron job: 'body hash did not verify'.
One common problem with OpenDKIM are irregular line endings. RFC 5322 states that 'CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body.' So maybe the messages send by you manually have correct line endings, but the ones send by a cron job do not. You can try to set 'FixCRLF yes' in the config of OpenDKIM.
Despite whether this is the cause, you can enable 'KeepTemporaryFiles' in OpenDKIM: 'Instructs the filter to create temporary files containing the header and body canonicalizations of messages that are signed or verified. The location of these files can be set using the TemporaryDirectory parameter. Intended only for debugging verification problems.' That way you can compare the original body and the one delivered to GMail and probably find out what's the difference that causes the validation error.
Redd HerringRedd Herring
Not the answer you're looking for? Browse other questions tagged postfixgmaildkim or ask your own question.
Spoofing is a common challenge that enterprises face in today’s world, which can lead to increased spam and more intensified phishing campaigns. In order to reduce spoofing and provide a safer client experience, Office 365 now supports inbound validation of DomainKeys Identified Mail (DKIM) over IPv4, and Domain-based Messaging and Reporting Compliance (DMARC). Both of these technologies check for trusted authenticated senders and help identify untrusted ones that that fail authentication. Exchange Online Protection (EOP), which filters every single mailbox on Office 365, had previously supported Inbound DKIM for IPV6. With these added functionalities feature, Office 365 users can expect better brand protection and an even safer experience.
Let’s take a closer look at these new service features.
Domain-based Messaging and Reporting Compliance (DMARC)
DMARC is a technology designed to combat email spoofing and is useful to stop phishing. Specifically, it protects the case where a phisher has spoofed the 5322.From email address, which is the email address displayed in mail clients like Outlook and outlook.com. Whereas the Sender Policy Framework, (SPF) catches the case where the phisher spoofs the 5321.MailFrom, which is where bounce messages are directed, DMARC catches the case that is more deceptive.
A phishing message spoofing a financial institution but failing DMARC.
DMARC protects users by evaluating both SPF and DKIM and then determines if either domains matches the domain in the 5322.From address. In the example above, the phisher has passed SPF for phishing.com, but because phishing.com does not equal woodgrovebank.com, it fails DMARC.
The results of a DMARC check are stamped in the Authentication-Results header:
Office 365 then uses DMARC to mark the message as spam and provide better protection for its users. For more details, please see the blog post, Using DMARC in Office 365.
DomainKeys Identified Mail (DKIM)
DKIM permits the person, role or organization, who owns the signing domain, to claim some responsibility for a message by associating the domain with the message. Senders insert a digital signature into the message in the DKIM-Signature header, which receivers then verify. DKIM allows senders to build domain reputation, which is important to ensure email delivery and provides senders a non-spoofable way to identify themselves. It is a critical component of email protection. Office 365 previously supported DKIM when a message was sent over IPv6 and now supports it when it is sent over IPv4.
The results of a DKIM verification are written to the Authentication-Results header. For example, if the signing domain in the d= field in the DKIM-Signature header is d=example.com:
If a message fails DKIM verification, the header will say dkim=fail with the reason for the failure in parentheses, for example invalid body hash, key query timeout, no key for signature, and so forth.
Office 365 verifies DKIM signatures when receiving the message. However, after the message has been scanned, (lands in a user inbox, or is relayed to an on-premises mail server, is bcc’ed via a policy rule and so forth), the existing DKIM-Signature may no longer verify if a downstream mail server tries to re-verify it. This is because Office 365 modifies some parts of the message. We will be changing this behaviors in a subsequent release of Exchange Online Protection.
For more information on DKIM, please see RFC 6376 and dkim.org.
A message with a digital signature attached.
A message with a digital signature attached.
These two features are currently being rolled about and will be fully deployed by the end of the first quarter of 2015.These features help improve the Office 365 experience by helping reduce both phishing and spam in the service and we look forward to more secure experiences as we continue to add new capabilities to Exchange Online Protection (EOP).
—Terry Zink is a program manager and Shobhit Sahay is a technical product manager on the Office 365 team.