Veröffentlicht wurde die Technik am 18. Dezember 2023 von Timo Longin, Senior Security Consultant bei SEC Consult in Wien, gemeinsam mit dem dortigen Vulnerability Lab. Der Name SMTP Smuggling ist an HTTP Request Smuggling angelehnt, und die Analogie trägt: Dort entsteht der Angriff aus einer Uneinigkeit zwischen Frontend und Backend darüber, wo ein HTTP-Request endet – über Content-Length gegen Transfer-Encoding. Hier entsteht er aus einer Uneinigkeit zwischen zwei MTAs darüber, wo die Nutzdaten einer SMTP-Transaktion enden.

Damit gehört SMTP Smuggling in die Klasse der Parser-Differentiale. Dies sind Fehler, die nicht in einem Produkt liegen, sondern in der Kombination zweier Produkte mit jeweils für sich vertretbarem Verhalten. Diese Einordnung ist relevant, weil sie erklärt, warum ein Schwachstellenscan gegen ein einzelnes System die Angriffsfläche nicht abbildet.

Die End-of-Data-Sequenz

RFC 5321 legt fest, dass die mit DATA eingeleiteten Nutzdaten mit der Sequenz . enden – also einem Punkt allein auf einer Zeile, umschlossen von standardkonformen Zeilenenden.

Die Ursache des Problems ist historisch. Sendmail akzeptierte vor Jahrzehnten zusätzlich das nicht standardkonforme einzelne als Zeilenende. Aus Kompatibilität mit Software, die dieses Verhalten voraussetzte, zogen Postfix und Exim nach. Diese Toleranz gegenüber fehlerhaften Zeilenenden ist heute die Angriffsfläche.

Funktionsweise

Der Angriff benötigt zwei Systeme in bestimmten Rollen:

Server A (ausgehend) nimmt vom authentifizierten Angreifer eine Nachricht entgegen, die im Nachrichtentext eine nicht standardkonforme End-of-Data-Sequenz enthält, etwa .. Server A erkennt diese Sequenz nicht als Ende der Daten, behandelt sie als gewöhnlichen Text und gibt sie beim Weiterleiten unverändert aus.

Server B (eingehend) interpretiert genau diese Sequenz als Ende der Daten. Alles, was danach folgt, liest Server B nicht mehr als Nachrichteninhalt, sondern als neue SMTP-Kommandos: MAIL FROM, RCPT TO, DATA.

Server A sendet eine Nachricht. Server B empfängt zwei. Die zweite trägt einen Envelope-Sender, den der Angreifer frei gewählt hat.

Schematisch aufgebaut sieht der Nachrichtentext so aus:

MAIL FROM:<angreifer@bei-a-gehostet.tld>
RCPT TO:<opfer@ziel.de>
DATA
Subject: unauffaellige Nachricht

Erster Nachrichtentext
<LF>.<CR><LF>
MAIL FROM:<buchhaltung@bei-a-gehostet.tld>
RCPT TO:<opfer@ziel.de>
DATA
From: Buchhaltung <buchhaltung@bei-a-gehostet.tld>
Subject: Rechnung 2026-0815

Geschmuggelte Nachricht
<CR><LF>.<CR><LF>

Warum die Authentifizierung die E-Mail bestätigt

Der entscheidende Punkt: Die geschmuggelte Nachricht wird von Server A ausgeliefert. Sie kommt also von einer IP-Adresse, die im SPF-Record der bei A gehosteten Domain autorisiert ist.

SPF beantwortet die Frage, ob ein bestimmter Server für eine bestimmte Domain senden darf. Die Antwort lautet korrekt „ja". Das Alignment zwischen Envelope-Sender und From-Header stimmt, DMARC ergibt pass. Die Prüfung wurde nicht umgangen – sie wurde korrekt durchgeführt und liefert ein korrektes Ergebnis auf eine Frage, die den Angriff nicht erfasst. Der Angreifer fälscht keine Autorisierung, er verwendet eine echte.

Für die Erkennung bedeutet das, dass die üblichen Indikatoren ausfallen. Der Authentication-Results-Header ist unauffällig, Anti-Spoofing-Regeln auf Basis von DMARC-Ergebnissen greifen nicht, und der Empfänger sieht eine Nachricht, die technisch verifiziert erscheint.

Betroffene Konstellationen

Longin demonstrierte ausgehendes Smuggling unter anderem über Microsoft Exchange Online sowie die Dienste von Ionos/GMX. Beide Anbieter haben nach der Meldung nachgebessert.

Für eingehendes Smuggling identifizierte er die Standardeinstellung des Parameters CR and LF Handling in Cisco Secure Email – sowohl On-Premises als auch in der Cloud-Variante. SEC Consult schätzte die Zahl betroffener Instanzen auf über 40.000. Cisco bewertete den Sachverhalt nicht als Schwachstelle, sondern als beabsichtigtes Verhalten, und änderte den Standardwert nicht. Die Empfehlung lautet daher, die Einstellung manuell von Clean auf Allow zu ändern, damit die nicht standardkonforme Sequenz unverändert weitergereicht und vom nachgelagerten Server abgelehnt wird.

Nach der Veröffentlichung wurden CVEs für die verbreiteten Open-Source-MTAs vergeben: Postfix (CVE-2023-51764), Sendmail (CVE-2023-51765, bis einschließlich 8.17.2) und Exim (CVE-2023-51766, vor 4.97.1; dort nur, wenn eingehend sowohl PIPELINING als auch CHUNKING angeboten werden).

Die Offenlegung

Wietse Venema, Autor von Postfix, hat den Ablauf der Veröffentlichung öffentlich kritisiert: Sie erfolgte wenige Tage vor der Weihnachtspause und den in vielen Unternehmen damit verbundenen Change Freezes, und die Postfix-Maintainer hatten die entscheidenden Informationen vorab nicht erhalten. Aus seiner Sicht wurde damit faktisch ein Zero-Day publiziert. Postfix veröffentlichte am 22. Dezember gepatchte Versionen, die CVEs folgten am 24. Dezember.

Interessant daran ist weniger die Schuldfrage als das strukturelle Problem: Bei einer Angriffsklasse, die erst aus der Komposition zweier Produkte entsteht, ist keine Herstellerorganisation allein zuständig. Etablierte Disclosure-Prozesse sind auf Produkt-zu-Hersteller-Beziehungen ausgelegt und bilden diesen Fall nicht ab.

Praktisch relevant ist zudem, dass Postfix eine eigene Seite zu Falschmeldungen von Testwerkzeugen pflegt. Mehrere Scanner melden nicht funktionsfähige Angriffsmuster als Verwundbarkeit. Wer ein Scan-Ergebnis bewertet, sollte das berücksichtigen.

Gegenmaßnahmen

Postfix (ab 3.8.5, 3.7.10, 3.6.14, 3.5.24):

smtpd_forbid_bare_newline = normalize
smtpd_forbid_bare_newline_exclusions = $mynetworks

normalize verarbeitet ein einzelnes wie , verlangt für das Ende der Daten aber die Standardsequenz. Die strengere Variante reject weist Nachrichten mit fehlerhaften Zeilenenden ab und lehnt damit häufiger auch legitime Mail ab. Die Ausnahme für mynetworks ist sinnvoll, weil interne Clients – Health Checks von Loadbalancern, Multifunktionsgeräte, selbstgeschriebene Skripte – SMTP oft unsauber implementieren. Auf den Ständen 3.8.4, 3.7.9, 3.6.13 und 3.5.23 lautete die Empfehlung smtpd_forbid_bare_newline = yes; das ist heute ein Alias für normalize.

Als kurzfristige Maßnahme, versionsunabhängig:

smtpd_data_restrictions = reject_unauth_pipelining
smtpd_discard_ehlo_keywords = chunking, silent-discard

Das unterbindet unautorisiertes Command Pipelining und BDAT, adressiert aber keine fehlerhaften Zeilenenden. Es ist eine Übergangslösung, kein Ersatz.

Exim ab 4.97.1, Sendmail auf aktuellem Stand, Cisco Secure Email mit angepasstem CR/LF-Handling.

Wichtiger als die einzelne Einstellung ist die Betrachtungsweise. Zu prüfen ist nicht nur der eigene eingehende MTA, sondern die gesamte Kette davor: Secure E-Mail Gateway, Cloud-Filter, Archivierungs-Relay, Appliance im Rechenzentrum. Jede Abfolge zweier MTAs mit unterschiedlicher Toleranz gegenüber Zeilenenden ist ein Kandidat – auch dann, wenn jedes Glied für sich als aktuell gepatcht gilt.

Fazit

SMTP Smuggling zeigt, dass E-Mail-Authentifizierung nur so belastbar ist wie der Transportweg, auf dem sie geprüft wird. SPF, DKIM und DMARC beantworten die Frage, ob ein Server für eine Domain senden darf. Sie beantworten nicht, ob die Nachricht, die dabei entstanden ist, überhaupt von diesem Absender stammt.

Für die Praxis folgt daraus zweierlei. Ein DMARC-pass ist ein Indiz für Authentizität, kein Beweis; Prozesse für Zahlungsfreigaben oder Stammdatenänderungen sollten nicht allein darauf aufbauen. Und Interpretationsdifferenzen zwischen Systemen sind eine eigene Fehlerklasse, die in der Bewertung einzelner Komponenten strukturell nicht sichtbar wird.

Quellen