This is a spectacular suite of packages, it was fun to set up and I am running into my first real issue. DKIM is properly configured but fails only when sent to 365 citing body signing failure. From looking into discussions, it may be necessary to only sign the headers (such as From, To, Date, Subject & MessageID). Is this possible and is there documentation I am not finding out there for this? TIA!
To kind of document this saga of mine, I wanted to share a post I found about moving from opendkim to amavis. However this led me down a path of spamassassin conflicting and it was beyond my understanding at the time so am back at Opendkim xD Has anybody had experience with moving from Spamassassin/Opendkim to Amavis/Amavis-new?
It would be interesting to find out why you specifically have this dkim issue. I have not seen other users reporting this. Therefore, could you go a little more in depth in the issue you’re seeing? Which exact error message do you have? Where do you observe it? What leads you to conclude that not signing the body is a solution? It might be interesting if this is a generic issue for all MiaB users.
To your question, opendkim looks like it’s very configurable perhaps there is an option there that is of interest to you.
1 Like
Thank you for your insight! What I am seeing is while DKIM passes validation with sites like dkimvalidator.com, emails sent to Exchange Online and Gmail hosted accounts go to quarantine and when I capture the headers of the affected messages, there is a failure in the verification for the hash of the body:
hVdZ1DX2g/EIgt+NHcp84yETkSAZXEusH9gf0teRT/8= Body Hash The hash of the canonicalized body part of the message as limited by the 'l=' tag.
frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= Expected Body Hash The generated body hash used to verify the signature
I found a couple of discussions with similar issues and a little more about the flow of mail through Postfix and Opendkim. In a thread they suggest using the FixCRLF flag but this has not resolved it.
Just found a discussion that is promising:
Unfortunately, postfix and OpenDKIM doesn’t support DKIM signing right before sending to final destination. OpenDKIM only support milter interface that only operates when postfix receives email. Yes, you can have workaround like postfix multi instance so the first instance will do rewriting and the second one will do signing, but I think it’s not worth in your case.
A response to this was the use of Advanced Filters in Postfix:
I solved this problem by using the postfix advanced filter and adding the opendkim milter on the final phase.
I agree this is highly peculiar that others have not encountered with MIAB. I might just wipe and reload the VM to start fresh.
After reading up on it a little, it might have something to do with the choice of using simple vs relaxed canonicalization. There was a report on this earlier which to be honest I didn’t quite understand at the time. This post explains it quite well and makes me wonder why we shouldn’t use relaxed/relaxed.
Also, I notice that the l= tag is mentioned. I don’t think that is sent by default by mailinabox. Did you do any modifications to the box? Are you using external DNS?
Could you post the full validation and authentication headers here?
Unfortunately I can’t properly test this at this time, as I’m running dkimpy instead of opendkim on my box, which could of course differ in implementation and/or configuration.
1 Like
Hello KiekerJan!
Thank you so much for the pointer and questions! The canonicalization sent me in a lot of directions and I ended up re-installing the OS fresh but it did not make a difference with the result. However, I noticed that pretty much all mail coming into 365 fails body hash! How TF are they passing without quarantine but mine through MIAB were not I wonder. My best guess is that this public IP I am using does not have a reputation yet so is just suspicious by default which is ironic for Gmail’s case given how its own service is misused and Google could give less of a care 
It has been a busy week being pulled in different directions but as a bandaid I have a transport rule to accept mail coming in at least for 365 and if it passes DMARC it allows it through without quarantine. Not ideal in case they are sent to other 365 tenants but for now it is satisfactory.
I am using external DNS because I could not get the glue records working with GoDaddy and I have not made any modifications as I am apprehensive about breaking things 
Given this, I did find my newest installation had duplicate Canonicalization entries in the /etc/opendkim.conf file (lines 13 and 52) and only the last was being observed (line 52).
How are you generating the emails that fail? Is it manually or programmatically.
I have no issues anymore (!) sending emails to either gmail or microsoft from the webmail or using an ipad/iphone. All my emails go through without being flagged as spam or any other errors. However in order to get to this point you need to get on a whitelist with MS as explained below. This does not solve the issue of the mismatch.
For google i needed to a txt record for google-site-verification
1 Like
That has to be it! It is a public IP from a block on an ISP plan (in a DMZ) so likely does not have a reputation built. I have been sending tests via RoundCube in four ways: plain-text short body, plain-text long body (>4Kb lorem ipsum generator), and short/long body in HTML with no change (because I saw some posts mentioning signature discrepancies based on length of body). Also testing with a command line tool called CMail with the same results. Google sent me down a rabbit hole but I learned a lot along the way Thank you for the info and the guide!