Forwarding‑friendly ARC/DKIM preservation in docker‑mailserver (Gmail line‑wrap gotcha)

[Mygod]

I’m running docker‑mailserver as a forwarder (SRS enabled, Rspamd ARC/DKIM signing). I hit a subtle issue where a single forwarded message land in Gmail spam with dkim=fail + arc=fail, while others pass.

After digging, the root cause was Postfix’s outbound SMTP client folding over‑long lines (>998 bytes), which happens after Rspamd adds ARC/DKIM. That single fold changes the body, invalidating upstream DKIM and our ARC seal downstream.

Evidence from Postfix logs:

postfix/smtp[...]: 04E1478C0: breaking line > 998 bytes with <CR><LF>SPACE

In the same message, Gmail shows arc=fail and dkim=fail. A different message without any line‑folding logs passes.

What my AI suggested to fix this: (codex resume 019c075c-e7b3-7470-8d14-596a6a0f95af)

• For a forwarding‑only setup, I override Postfix’s line length limit so outbound SMTP doesn’t fold lines, preserving DKIM/ARC.
• Safer variant: only disable folding for Gmail via a transport map override (keeps RFC‑strict behavior elsewhere).

Global override (simplest, forwarding‑only):

# /tmp/docker-mailserver/postfix-main.cf
smtp_line_length_limit = 0

Gmail‑only transport (safer if you forward to many domains):

# main.cf
transport_maps = texthash:/etc/postfix/transport

# /etc/postfix/transport
gmail.com smtp:gmail-relay
googlemail.com smtp:gmail-relay

# master.cf
gmail-relay unix - - n - - smtp
  -o smtp_line_length_limit=0

This keeps ARC/DKIM intact for Gmail while remaining RFC‑strict for other domains.

It’s not a DMS bug (Postfix is RFC‑correct), but it might be a useful documentation note for forwarders using ARC.

[polarathene]

Thanks for taking the time to share that back to the community! ❤️

Was the forwarded mail sent from Outlook with the References: header being the line that was folded? If so there's this related issue at the rspamd repo which documents the alternative workaround to not sign that header with DKIM.

I'm not too familiar with the details, so that might not work for your forwarding scenario 😅

---

UPDATE: Oh you mentioned it was the message body, not headers (I can't recall if the SMTP message part differentiates body/headers, but the checks condition below might imply it wouldn't solve the above linked header issue).

I think Postfix has you sorted with force_mime_input_conversion=yes (default: no):

Convert body content that claims to be 8-bit into quoted-printable, before header_checks, body_checks, Milters, and before after-queue content filters.
The typical use case is an MTA that applies this conversion before signing outbound messages, so that the signatures will remain valid when a message is later delivered to an MTA that does not announce 8BITMIME support, or when a message line exceeds the SMTP length limit.

That should modify the content before it's signed by Rspamd AFAIK, and that should work smoothly without the transport workaround 🤔

What encoding was the affected mail using? Could you confirm that it's not quoted-printable/base64?

Unfortunately, that is dependent upon Postfix 3.9+. DMS is presently on Debian 12 Bookworm (which packages Postfix 3.7) and I don't think we have the backports repo enabled (which provides Postfix 3.10), if we did I'd have expected it to be managed here. I could be mistaken as I haven't checked by running a DMS container, if we have got the newer Postfix already you're golden :)

You might need to wait until DMS v16 release (upgrade to Debian 13 Trixie) but we've been stalling on that due to contributors lacking time to push the Dovecot 2.3 => 2.4 upgrade forward (not semver, introduces breaking changes). Alternatively, extending our image with a custom Dockerfile (or compose.yaml with inline dockerfile) could add that backports repo to update the package.

---

I'm not too familiar with the impact of enabling that setting by default, it might present a breaking change for DMS to adopt but we could definitely document it. Quick look at encoding conversion from that Postfix setting is that quoted-printable encoding is pretty inefficient for non-ASCII languages apparently.

Besides if the References header is still valid problem that could be encountered your transport workaround might be more reliable.

[Mygod]

Preparing this note takes actually shorter time than what you'd imagine because it's mostly written by my coding agent. Debugging this issue took way more time. :)

To your questions, here's what my agent said:

Thanks for the thoughtful reply! A few clarifications from our side:

• This is a forwarding‑only setup, and preserving upstream DKIM at the forwarder is critical.
• The break we saw was not at the forwarder or in headers; it happened in Postfix’s outbound SMTP client. The log shows:
  postfix/smtp[...] breaking line > 998 bytes with <CR><LF>SPACE
  So the body was folded after Rspamd added ARC/DKIM, which is why Gmail saw dkim=fail + arc=fail.

Because of that, force_mime_input_conversion wouldn’t be ideal for us:

• It would rewrite the body before Rspamd signing, which would invalidate upstream DKIM at our server and reduce ARC usefulness for downstream recipients.
• Also, as you noted, it’s Postfix ≥3.9, and DMS is currently on 3.7 (Bookworm), so not available anyway.

So for a forwarder, the most practical fix is to avoid the line folding at outbound SMTP (smtp_line_length_limit = 0), which keeps upstream DKIM intact and allows ARC to validate. We’ve applied that and it resolves the issue.

Agree the Outlook/References: header case is a separate issue, but it doesn’t match what we saw here (body folding in logs).

Happy to share more logs if useful.

[polarathene]

here's what my agent said

I lack the time to reproduce and verify (I tend to be skeptical with taking agent advice blindly, even if it works I prefer to align by verifying externally). I've encountered AI advice that's outright wrong multiple times, so I'm wary of trusting any feigned confidence.

I don't know if upstream DKIM would be relevant in the forwarding context, any modifications DMS makes the DKIM signature to my understanding is to verify that trust for the next hop involved. ARC however is relevant for forwarding trust, but as my knowledge in this area is foggy I can't challenge the agent advice unless I verify.

Once we've upgraded DMS to Debian Trixie for the v16 release, perhaps I'll have time to verify.

[Mygod]

No worries. This is really just an one-off issue. This is probably the first email I encountered in the wild that has a line that's >998 bytes long. Unfortunately, I couldn't retrigger the email so I trust the fix for now unless I encounter another one. I believe that this issue is pretty niche and that's why I just decide to put it as a discussion in case others find it useful.

As far as I'm concerned, any changes to the email body would invalidate DKIM (including wrapping a super long line). I guess it might be possible that if ARC happens after wrapping then ARC signature could be fine, but it wouldn't help with DKIM breaking.

[polarathene]

As far as I'm concerned, any changes to the email body would invalidate DKIM (including wrapping a super long line). I guess it might be possible that if ARC happens after wrapping then ARC signature could be fine, but it wouldn't help with DKIM breaking.

Like I've said in my previous comment I'd need to verify, but my recall is these changes should not be a problem.

Here's what Google's "AI Overview" output had to say (since I haven't got time to refresh on the topics properly):

DKIM signatures verify email integrity and sender identity, but if an email passes through multiple intermediaries, only the latest, most recently added valid signature is typically crucial for authentication.
While an email can have multiple signatures, any modification in transit breaks the cryptographic hash, making the final, most recent signature the defining check for integrity

ARC (Authenticated Received Chain): If intermediary services alter messages, they can use ARC, which acts as a secondary verification mechanism to validate the original, pre-modification DKIM signature.

It works by creating a "chain of custody" for an email, allowing intermediate servers (such as mailing lists or forwarding services) to sign the original authentication results.

ARC solves the problem where legitimate forwarding breaks DMARC by allowing the final receiving server to verify that a message was properly authenticated before it was modified or forwarded.

Both of those definitions align with my recall and expectations, which would indicate that Postfix receiving the mail to forward, verifying the signatures and then applying it's own modification with Rspamd signing afterwards should avoid the problem.

So I'm inclined to disagree with your AI agent output as the information I just provided conflicts with what it was saying. Verification through a local offline reproduction I can setup when I have the time to spare will confirm if that's the actual case.

Even if I am right though, the solution I provided isn't necessarily any better unless there was some filter in place to only apply it when running into that length issue and that's just going to result in a similar workaround as to what you've setup (with some added complexity for the condition detection) if someone cared to minimize the scope of mail affected by the modification.

---

No worries. This is really just an one-off issue.

Fair, but thanks for sharing with the community! There's a few forwarding gotchas like these that users report, I may look into a FAQ item or similar for our docs at some point that at least keeps track with links referencing each of them for more information and workarounds.