Wann tritt das Problem auf?
Das Problem tritt auf, wenn eine E-Mail im SMTP-Transport LF (0x0A) statt der vorgesehenen CRLF-Kombination (0x0D 0x0A) als Zeilenabschluss enthält.
Dies kann insbesondere bei automatisiert erzeugten E-Mails vorkommen. Werden solche Nachrichten anschließend an ein SMTP-System übergeben, das die Nachrichten strikt nach den SMTP-/RFC-822-Regeln verarbeitet, kann die Zustellung abgelehnt werden.
Gerade bei Journaling Zielen führt das natürlich zu einem Anstieg der NDR Meldungen im JournalError Postfach.
Wie ist das technisch einzuordnen?
Für den SMTP-Nachrichtentransport ist CRLF der definierte Zeilenabschluss (RFC 5321, aufbauend auf den RFC-822-Regeln).
Unsere Lösung verarbeitet Nachrichten entsprechend diesen Vorgaben und erwartet weiterhin CRLF. Eine Änderung unserer Implementierung ist daher nicht vorgesehen.
Welche Möglichkeiten gibt es bei Microsoft 365?
Microsoft beschreibt für Exchange Online drei mögliche Ansätze:
Korrektur beim Absender
Der Absender erzeugt die Nachricht mit korrekten CRLF-Zeilenenden.
SMTP CHUNKING / BDAT
Die Nachricht wird über BDAT übertragen. Diese Option steht in unseren Lösungen (OnPrem via SMTP MailDepot Konnektor und im Cloud Konnektor unserer Cloud Lösung) nicht zur Verfügung.
Transportregel in Exchange Online
Microsoft beschreibt als Workaround eine eingehende Transportregel mit einem kleinen Disclaimer. Dadurch wird die
Nachricht so verarbeitet, dass die fehlende CRLF-Kombination ergänzt wird.
Die von Microsoft dokumentierte Vorgehensweise findet sich hier:
Microsoft Learn – SMTPSEND. BareLineFeedsAreIllegal NDR