Hi all, Heads-up for anyone who runs mailing lists, forwarders, or anything else that re-serializes headers from inbound mail.
Starting around 2026-09-30, some mail from iCloud (outbound.pv.icloud.com, d=me.com / icloud.com) arrives with its X-JNJ header folded using CR CR LF instead of CRLF, so every continuation line ends in a bare CR: X-JNJ: AAAAAAABP/3KSje4IZVa07c2z+UdxkhM9/vkiTEFbtICtmdQNDbg+DrLdQ0Ft9q0EVFmsf\r\r\n ZsqJKIQheNL00NIO5g3xDCPrPfJlm7dxlD87Eo/cBz7v93Mql2/2PgDogHunr59cSLoX67\r\r\n ... Nothing else in the message has bare CRs. Our numbers: of iCloud messages carrying X-JNJ, 0 of ~350–400/day had this from 09-27 through 09-29, then 123 of 392 (31%) on 09-30, which looks like a rollout still in progress. Many parsers tolerate it on the way in (Go's net/mail, for one), and iCloud's own DKIM signature doesn't cover X-JNJ, so it passes. The problem shows up downstream: a common line-reading approach strips the CRLF but leaves the bare CR in the header value, and writing the header back out produces \r\r\n. Gmail treats the bare CR as a line break, sees an empty line inside X-JNJ, and ends the header block there. iCloud puts X-JNJ before Content-Type and Content-Transfer-Encoding, so those land in the body: recipients see the raw MIME structure and base64 parts as plain text, and any DKIM signature you added fails with "body hash did not verify". The fix on our side was to strip trailing CRs from each header line on ingest. If you relay iCloud mail and have had recent reports of garbled messages or DKIM body-hash failures, this may be why. Suresh, could you pass this along to the appropriate people? Cheers, Mark Groups.io
_______________________________________________ mailop mailing list -- [email protected] To unsubscribe send an email to [email protected]
