ad DKIM verification issue:
The good news: It's not a bug in DkimX
The bad news: It's caused by the MXS transport service
>I'm kind of aware that Exchange does have the bad habit of modifying boundaries and reformatting whitespaces which will often break DKIM
As you already suspected, the verification issue with nested MIME multipart messages sent from Gmail accounts is caused by the fact that the MXS transport service 'beautifies' the body content of MIME messages before the messages are given to transport service agents like DkimX for further processing.
I found two idiosyncrasies (which both seem to be RFC-compliant!) in MIME multipart messages sent from Gmail which are affected by the 'beautification' (tell me when you are interested in the details).
The 'beautification' of the first idiosyncrasy would only break the 'Simple' body canonicalization hash, which is rarely used.
The 'beautification' of the second idiosyncrasy would break the 'Simple' and the 'Relaxed' body canonicalization hash, which is what you experienced.
As of now I found no way to prevent this unwanted 'beautification'.
ad DKIM signing issue:
>I'm also reporting you that the same issue apparently breaks signing too
I'm currently not able to reproduce the problem with DKIM signing, neither using OWA nor Outlook as client.
Could you please provide detailed information about how to reproduce the signing issue.
Yes I thought that was the case, but maybe the DKIM signing issue could also bring to a "resolution".
About how to replicate it I added in OWA a signature with rich text/html that has a tabled layout with a picture. I think that's about it otherwise I can provide some info about the setup:
- I run Exchange 2016 CU17 on both the mailbox servers and the edge server
- DkimX of course runs on the Edge Transport Server
- I use RSA-SHA-256 and relaxed/relaxed as header/body canonicalisation
- The receiving account was again Gmail
Strange as it is, Gmail sets the dkim flag in results as "neutral" instead of failed (but FAILED above in the higher part of the "Original message" view).
Maybe you could add a flag to do the same in DkimX verification configuration at least that's something which can be hooked upon in flow rules into ECP.
I can eventually provide samples if you need, if you have further difficulties replicating.
Let me know.