Hello,

We're currently evaluating DkimX for use on our Exchange 2016 Edge Transport Server, the problem is that it currently fails to verify any message which contains an attachment, testing it on other implementations (Spamassassin etc) which perform DKIM verification will PASS the messages (by the way sent using a gmail account).

DMARC / DKIM verification is the main feature which we need it for so that's a big blocker at the moment. I'm kind of aware that Exchange does have the bad habit of modifying boundaries and reformatting whitespaces which will often break DKIM, and that is my first hypothetical culprit.
DkimX Verifier is also set as the first transport agent priority wise.

Have any insight?

Hi Maranda,

thank you for notifying me about this issue. I could reproduce the reported issue using an GMAIL account. As soon as I know more I will report it here.

Regards,
Franz

Hello Franz,

I'm also reporting you that the same issue apparently breaks signing too, after riff-raffing with it a bit I discovered the same thing happens when sending from OWA with signatures or attachments, but only via OWA if I send the message through EWS in Outlook the message doesn't fail verification.

Something looks to be amiss with multipart messages, possibly because it doesn't look to be possible to get the raw bytes of a message as it was transmitted via the Exchange APIs?

Hope it helps.

Hello Miranda,

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.


Thank you,
Franz

Hello Miranda,

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.


Thank you,
Franz

Hi Franz,

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.

Best regards,
Marco.

Hi Marco,

>I can eventually provide samples if you need, if you have further difficulties replicating.

you could help me very much if you perform the following steps:

1.) Please send an OWA message, which should reproduce the problem, to the following recipients:

[hidden]

2.) If you receive after some minutes a response from [hidden], please forward this message to me, [hidden].

Thank you in advance,
Franz

Ad DKIM signing issue:

After analyzing the provided data (thanks!) I found the cause of the DKIM signing issue on MXS 2016/2019 Edge servers and can also suggest two workarounds.

Cause:
If a message containing an image or attachment, whose filename is longer than ca. 56 characters, is processed by the Attachment Filtering Agent, which exists only on Edge servers. In this case the Attachment Filtering Agent folds a MIMEPART header line into two text lines. After DkimX signs the message (containing the folded header line) and then saves the changes, the Transport Service 'beautifies' the message content by unfolding the two text lines into one, thereby invalidating the DKIM hash.

Workarounds:
1.) If you do you not require the functionality provided by the Attachment Filtering Agent on MXS 2016/2019 Edge servers, you can just disable this agent (Disable-TransportAgent).
2.) If you want to use the Attachment Filtering Agent for processing of inbound messages from the Internet, you should configure the receive connector for outbound messages from the Intranet as excepted (Set-Attachmentfilterlistconfig), to prevent processing of outbound messages by the Attachment Filtering Agent.

-Franz