[DKIM] Use of relaxed/simple cannonicalization can lead to invalid DKIM signatures for long header lines

[ichdasich]

Currently, mail in a box configures opendkim to use relaxed/simple canonicalization (ll34 https://github.com/mail-in-a-box/mailinabox/blob/main/setup/dkim.sh ). This can lead to verification issues with long To: headers; Specifically, whitespaces/\r\n/\n get injected, which let verification fail, see https://www.rfc-editor.org/rfc/rfc6376#section-3.4 and https://www.rfc-editor.org/rfc/rfc6376#section-3.5.

(I am currently a bit unsure why this is an issue for relaxed/simple being used; Technically this should be a simple/(relaxed|simple) issue).

This does only cause issues for very long To: headers.

Reproducing the issue

To test this:

• start a test for a system using mail-in-a-box here: https://www.email-security-scans.org/ (select "store emails for me")
• Wait for measurement mail to arrive and reply
• See that DKIM verification failed
• Download all data and extract it.
• Run manual verification with dkimpy: sent-messages % cat 1.mbox | dkimverify -> signature verification failed
• Edit the message and fix the broken headers (most likely To: having newlines added)
• Rerun verification: sent-messages % cat 1.mbox | dkimverify -> signature ok

This issue also reproduces when sending to, e.g., google. To test that, start a test (or create a long to yourself), but this time before sending the test message, add a gmail address to the To: as well. You will see that the mail is not validated by Gmail anymore.

Suggested solution

Switch to relaxed/relaxed canonicalization for DKIM signing.

[kiekerjan]

Interesting.
I'm running this branch which does not seem to have this issue. All the mails tell me signature ok. Is this issue inherent to the relaxed/simple canonicalization, or might it be a software bug in opendkim?

[ichdasich]

Oh, interesting observation; Can you maybe setup both branches to send from, and store the emails on the test platform to compare? It might indeed be opendkim then (also explains why I have seen the same issue in other setups).

I currently do not really have the time to test this. :-/

[kiekerjan]

I took some time to test this. I tested the following three installations:

1. Clean installation of the main branch of mail-in-a-box
2. Upgrade installation from 1 with the 2220 branch
3. Clean installation of the 2220 branch

Actually, for all three installations the dkim signatures were deemed valid by the https://www.email-security-scans.org/ tester. I could not reproduce the issue mentioned in the issue report.