SMTP smuggling was disclosed in December 2023 by Timo Longin, a researcher at SEC Consult. The name is borrowed from request smuggling, a well-known class of HTTP attacks that work the same way: two systems process the same byte stream, they disagree about where a boundary sits, and the attacker lives in the gap between the two interpretations. Where HTTP smuggling targets web servers and proxies, SMTP smuggling targets the mail pipeline — the chain of servers that relay a message from sender to inbox.
To see how it works, you have to look at the single most boring detail in the entire email protocol: the sequence of bytes that marks the end of a message body.
The End-of-Data Sequence
When a sending server transmits a message, it issues the DATA command, streams the headers and body, and then signals the end with a very specific sequence: a carriage return and line feed, a single dot on its own line, and another carriage return and line feed. In notation, that is <CR><LF>.<CR><LF> — often written \r\n.\r\n. The receiving server watches for exactly that sequence and treats everything before it as one message.
The standards are explicit that \r\n.\r\n is the terminator. The problem is that not every server enforces it strictly. Over decades, many implementations grew lenient and also accepted malformed variants as an end-of-data signal — a bare line feed without the carriage return (\n.\n), or a bare carriage return (\r.\r). They did this to be forgiving of slightly broken senders, in the spirit of the old robustness principle: be liberal in what you accept.
The attack exists entirely because the outbound server and the inbound server disagree about which byte sequences end a message. One sees a single message; the other sees two. Everything else follows from that single inconsistency.
Smuggling a Second Message
Here is the maneuver. The attacker has a legitimate account on some provider — call it the outbound server — and can send authenticated mail through it. That outbound server correctly stamps the message with valid SPF and DKIM for the attacker's own domain. So far, nothing is forged.
But inside the body of that legitimate message, the attacker embeds a non-standard end-of-data sequence — say a bare \n.\n — followed by a brand-new, complete SMTP message: a fresh MAIL FROM, a fresh set of headers, and a body. The crucial detail is what each server does with this:
- The outbound server does not recognize the bare
\n.\nas a terminator. It treats the whole thing — the legitimate message plus the smuggled payload — as a single message body and relays it onward, with valid authentication for the attacker's domain. - The inbound server at the victim's provider does accept the bare
\n.\nas end-of-data. So it splits the stream into two messages. The first is the attacker's harmless cover message. The second is a wholly separate email — with a forged sender of the attacker's choosing.
That second, smuggled message was never authentication-checked as its own message. It rode in on the back of the first one. The receiving server treats it as having arrived over an already-trusted connection from a reputable provider, so the spoofed MAIL FROM — which can claim to be any domain, including ones with strict DMARC policies — sails through.
The forged message doesn't break SPF, DKIM, or DMARC. It is simply never subjected to them as an independent message, because the inbound server thinks it already vouched for the connection that delivered it.
Why This Was Dangerous
Sender authentication is the foundation that a lot of anti-phishing depends on. When a recipient's mail client shows a message as passing DMARC for, say, a bank's domain, both automated filters and trained humans treat that as a strong signal of authenticity. SMTP smuggling let an attacker manufacture exactly that signal for domains they had no business sending from.
The original research found the technique worked against the infrastructure of major providers and several widely deployed mail servers, including implementations of Postfix and Exim. Because the flaw lived in the interaction between two servers rather than in any single configuration, it affected the ecosystem broadly rather than one product.
How It Was Fixed
The fix is conceptually simple and matches the lesson of every smuggling attack: stop being lenient about message boundaries. Servers were hardened to reject — or to refuse to treat as end-of-data — the malformed bare-newline and bare-carriage-return sequences, accepting only the standard \r\n.\r\n.
Postfix, for instance, added configuration controls (such as smtpd_forbid_bare_newline) to reject messages containing bare line feeds rather than silently normalizing them, and major mail providers tightened their inbound parsing. Once both ends of the pipeline agree that only the canonical terminator counts, the gap the attacker lived in disappears.
| Server role | Vulnerable behavior | Hardened behavior |
|---|---|---|
| Outbound (relaying) | Passes bare-newline bytes through unchanged | Rejects or normalizes non-standard line endings before relay |
| Inbound (receiving) | Accepts \n.\n as end-of-data |
Only \r\n.\r\n ends a message; bare newlines refused |
The Pattern Worth Remembering
SMTP smuggling is a textbook parser differential: a vulnerability that arises not because any one component is broken, but because two components interpret the same input differently. This class of bug shows up everywhere two parsers sit in series — HTTP request smuggling, Unicode normalization mismatches, filename handling between an upload validator and the filesystem. The defense is always the same principle: at trust boundaries, be strict, not lenient. The robustness principle — "be liberal in what you accept" — is good advice for interoperability and quietly terrible advice for security.
For the average user there was nothing to do but wait for providers to patch, and they largely have. But the episode is a useful reminder of what email authentication does and doesn't guarantee. SPF, DKIM, and DMARC are real and worth having, yet they protect a specific thing — the binding between a message and a sending domain — and that protection is only as strong as the agreement between the servers that pass the message along. When two machines disagree about where a message ends, even perfect cryptography on each message can't save you, because the question of which bytes are the message was answered wrong before the crypto ever ran.