Das Problem

Eine Versandbenachrichtigung mit dem Betreff “Ihre Lieferung verzögert sich” wird von Dynamics NAV erzeugt und über Exchange verschickt. Der Empfänger bei mail.de bekommt die Mail nie — stattdessen kommt ein Bounce zurück:

550-5.6.0 Reject; strict 7bit header encoding required;
Header name: Subject offset: 19

Position 19 im Subject — das ist das “ö” in “verzögert”. Der empfangende Server verlangt, dass Non-ASCII-Zeichen im Header RFC 2047-konform encodiert werden, also sowas wie:

Subject: =?UTF-8?Q?Ihre_Lieferung_verz=C3=B6gert_sich?=

Stattdessen kommt rohes UTF-8 an. mail.de lehnt korrekt ab — das ist kein Bug dort, sondern ein Standard-Verstoß auf Absenderseite.

Der Instinkt (falsch)

Erste Idee: Postfix-Relay zwischen NAV und Exchange/Smarthost schalten, das die Header nachträglich encodiert. Zweite Idee: NAV-Codeunit anpassen. Dritte Idee: den Smarthost-Betreiber bitten.

Alles Overkill. Die Lösung ist ein einzelner PowerShell-Befehl.

Die Diagnose

Der Mailfluss sieht so aus:

srv-r2d2 (NAV) → mail-obiwan (Exchange) → Smarthost → Internet

NAV liefert die Mail per SMTP Submission an Exchange ein. Exchange sollte die Header im Transport-Pipeline RFC 2047-encodieren — tut es aber offensichtlich nicht. Also: Exchange-Konfiguration prüfen.

Schritt 1: Remote Domain Settings

Get-RemoteDomain | fl Name, CharacterSet, NonMimeCharacterSet, ContentType

Name                : Default
CharacterSet        : iso-8859-1
NonMimeCharacterSet : iso-8859-1
ContentType         : MimeHtmlText

ISO-8859-1 kann “ö” darstellen — das ist nicht das Problem.

Schritt 2: Send Connector

Get-SendConnector | fl Name, *encoding*, *convert*, *mime*

Keine encoding-relevanten Properties gesetzt. Standard-Verhalten.

Schritt 3: Der Treffer

Get-OrganizationConfig | fl ByteEncoderTypeFor7BitCharsets

ByteEncoderTypeFor7BitCharsets : 0

Da ist der Übeltäter.

Die Ursache

ByteEncoderTypeFor7BitCharsets steuert, wie Exchange mit Nicht-7-Bit-Content in ausgehenden Mails umgeht. Der Standardwert 0 bedeutet: Exchange macht keine erzwungene Encodierung. Wenn NAV den Subject-Header mit rohem UTF-8 einliefert, reicht Exchange das unverändert durch.

Die meisten Mailserver schlucken das trotzdem — aber Server mit strikter RFC-Prüfung wie mail.de lehnen korrekt ab.

Die Lösung

Ein Befehl in der Exchange Management Shell:

Set-OrganizationConfig -ByteEncoderTypeFor7BitCharsets 13

Wert 13 = Exchange erzwingt UTF-8-Encoding mit 7-Bit-sicherer Ausgabe für alle ausgehenden Mails. Subject-Header mit Umlauten werden automatisch RFC 2047-konform encodiert.

Verifizieren

Get-OrganizationConfig | fl ByteEncoderTypeFor7BitCharsets
# Erwartet: 13

Danach eine Test-Mail mit Umlaut im Betreff an eine @mail.de-Adresse schicken und prüfen, ob sie ankommt.

Rollback

Falls wider Erwarten Probleme auftreten:

Set-OrganizationConfig -ByteEncoderTypeFor7BitCharsets 0

Warum das kein Risiko ist

  • RFC 2047-Encoding ist der Standard seit 1996 — jeder Mailserver der Welt versteht das
  • Die Einstellung ist org-weit, betrifft also alle ausgehenden Mails — aber korrekt encodierte Header sind nie ein Problem
  • Die Änderung macht Exchange RFC-konformer, nicht weniger

Betroffen: Nicht nur mail.de

Das Problem tritt bei jedem Empfänger mit strikter Header-Prüfung auf. mail.de ist nur einer davon. Die Dunkelziffer ist vermutlich höher — viele Bounces landen in Postmaster-Postfächern, die niemand liest.

Wenn du Dynamics NAV oder Business Central mit Exchange betreibst und deutschsprachige Betreffzeilen versendest, prüf den Wert. Kostet 30 Sekunden.

Referenzen