DKIM signing and ARC sealing order is reversed

[ykasap]

Sympa performs DKIM signing after ARC sealing.

According to section 5.1 of RFC8617, "All message modifications (including adding a DKIM-Signature header field(s)) MUST be performed before sealing." This seems to be a regression introduced by PR #1452.

Also, please consider including DKIM-Signature header in ARC-Message-Signature.

RFC8617 section 4.1.2:

To preserve the ability to verify the integrity of a message, the signature of the AMS header field SHOULD include any DKIM-Signature header fields already present in the message.

Version

Sympa 6.2.72 on FreeBSD 14.1

Installation method

pkg install sympa (which installed sympa-6.2.72_2).

Expected behavior

Perform DKIM signing before ARC sealing. ARC-Message-Signature includes DKIM-Signature header fields.

Actual behavior

A DKIM-Signature header is prepended after ARC headers. ARC-Message-Signature doesn't include DKIM-Signature header fields.

Steps to reproduce

Send a message to a mailing list on DKIM/ARC-enabled Sympa instance, receive the message, and check the headers

Additional information

[speterson7]

I have seen this same problem and am wondering if it is responsible for both Google and Outlook to fail the ARC tests for email sent from my sympa server. Have you found a work-around?

[ykasap]

@speterson7 In my test setup, Google passed ARC tests for emails distributed via my Sympa instance even without a workaround, so the cause of your problem might be different. OTOH, Exchange Online failed the tests, so I'm trying to find the culprit. I modified Sympa to do ARC Sealing after DKIM Signing, but the issue persisted. Then, I tried to include DKIM-Signature in AMS by adding the headers option for Mail::DKIM::ARC::Signer, but it didn't work for an unknown reason.

I also tried Rspamd for DKIM/ARC processing instead of Sympa, and both Google and ExO passed the ARC test. However, I have yet to discover why Sympa's ARC implementation doesn't work as intended.

[ikedas]

@speterson7 , at least on the lists of sympa.community, neither Google nor Outlook reject the messages sent via these lists because of failure of ARC tests.

@ykasap , I made the modification following your suggestion: ikedas/sympa@3402626 . Is this the same as the modification you made?

[ykasap]

My modification was crude (effectively reverting the PR) for testing, so it is not the same, but it looks good to me.

[ikedas]

Could you try again with my patch to check if the problem will be reproduced with Google, Outlook etc.?

[ykasap]

Your patch fixed the order of ARC and DKIM, and the dkim-signature is included in AMS, which seems fine.

Gmail passed the ARC test, but Exchange Online didn't (the same as the ARC without your patch). It is hard to investigate further because Exchange Online returns "arc=fail (47)" without details in the AAR header (I can't find what "47" means).

Exchange Online accepts Rspamd's ARC, so there must be a way to fix the problem. Fixing #1852 didn't improve the result. I might configure something wrong for Sympa, so I'll investigate further when I have time.

[ikedas]

@ykasap , can you provide sample of the messages, ARC-sealed by Rspamd and by Sympa? I'd like to investigate it (if you aren't comfortable publishing the messages, send them to the e-mail address on my profile page).

Another possibility I can think of is that the trusted ARC sealers setting on Outlook is having an effect. ARC seals by the site that are not trusted by the recipient's site may not be valid.

[ykasap]

@ikedas I'm afraid I don't want to disclose these messages here because they include a private domain name and some email addresses I own that I used for my (somewhat lazy) test environment. Because it involves signature verification, I cannot obfuscate them. I'll send samples privately.

I have already tested trusted ARC sealers. They are used to override the DMARC failure with ARC information from trusted ARC sealers after the ARC check is passed, and they won't change arc=fail to arc=pass. AAR includes arc=pass(... oda=1 ...) when the sealer is trusted. If not, oda=0.

[ikedas]

@speterson7 & @ykasap ,

What about the key length? At present, it is recommended that 2048-bit key with rsa-sha256 is used for ARC unless there are special reasons.

鍵長はどうなっていますか。現状では、特に理由がない限りARCではRSA-SHA256の2048ビット鍵を使うのがいいと思います。

[ykasap]

I upgraded the key length to 2048, but the result was the same (Rspamd's ARC passed, and Sympa's ARC failed at Exchange Online).

[ikedas]

Can you apply additional patch ikedas/sympa@147e702 ?

[ykasap]

I applied the additional patch and tested it, but the result was the same...

[ikedas]

ARC認証が失敗する原因はExchange Onlineの側にあるようにも思えます (たとえば、受信者のOutlookアカウントを削除して新たに作成し直しても結果は同じでしょうか)。いずれにしても、Microsoftが「47」というエラーコードの意味を開示してくれない限り、我々にはこれ以上の調査はできないと思います。

当イシュー自体は提示されているパッチで解決されるので、ここは一旦閉じることにして、新たな情報が得られたら再度イシューを起票していただけないでしょうか。

It seems that the cause of the ARC authentication failure could be on the part of Exchange Online (for example, if you delete the recipient's Outlook account and create it anew, would the result be the same?). In any case, we may not be able to investigate further unless Microsoft discloses the meaning of error code "47".

Since the issue itself will be resolved by presented patch, could you please close this, and when you have new information, submit another issue?

[ykasap]

I agree with you. I will close this issue and open another one when I find new information.

了解しました。元々の問題は修正されたと思いますので、一旦この issue は閉じさせていただきます。何か気づいたらまた報告させていただきます。

ありがとうございました。