When Does This Problem Occur?
This problem occurs when an email in SMTP transport contains LF (0x0A) instead of the expected CRLF combination (0x0D 0x0A) as a line break.
This can occur particularly with automatically generated emails. If such messages are subsequently forwarded to an SMTP system that processes messages strictly according to SMTP/RFC-822 rules, delivery may be rejected.
This naturally leads to an increase in NDR messages in the JournalError mailbox, especially for journaling destinations.
How should this be understood from a technical perspective?
For SMTP message transport, CRLF is the defined line break (RFC 5321, based on the RFC 822 rules).
Our solution processes messages according to these specifications and continues to expect CRLF. Therefore, we do not plan to change our implementation.
What options are available in Microsoft 365?
Microsoft describes three possible approaches for Exchange Online:
Correction by the sender
The sender creates the message with correct CRLF line endings.
SMTP CHUNKING / BDAT
The message is transmitted via BDAT. This option is not available in our solutions (OnPrem with SMTP MailDepot Connector and Cloud Connector in our Cloud solution).
Transport Rule in Exchange Online
Microsoft describes a workaround involving an inbound transport rule with a short disclaimer. This causes the message to be processed in such a way that the missing CRLF combination is added.
The procedure documented by Microsoft can be found here:
Microsoft Learn – SMTPSEND. BareLineFeedsAreIllegal NDR
SPAM Emails in Quarantine
Policy "Action for spam messages" from "Move message to Junk Email folder" to "Quarantine message" (analogous to the other categories).
Impact:
Spam emails are then held in quarantine instead of being delivered to the mailbox → no more journal triggering for these cases.
As a result, users lose the self-service capability to view/release junk emails directly in their own Junk folder – instead, they would have to release them via the quarantine notification/quarantine portal (if desired). This is a deliberate trade-off between convenience and precisely this side effect (journaling + potential NDRs for spam emails with missing CRLF).
