Quick Answer
SMTP smuggling is a class of spoofing technique disclosed in December 2023 by researcher Timo Longhi, in which attackers send specially crafted sequences of end-of-data characters that trick receiving mail servers into treating attacker-controlled conversation lines as a new, legitimate message — one that often passes SPF and DMARC because it appears to come from the receiving server’s own domain. CVE-2023-51764 (Postfix and wider MTA families) and CVE-2023-51765 (additional implementations) anchored the family. The demonstration that mattered: spoofed messages landing in DHL and other enterprise inboxes passing all authentication checks, days before the patch ecosystem fully caught up.
The finding mattered because email authentication — SPF, DKIM, DMARC — had been sold as the end of sender spoofing. SMTP smuggling showed the authentication layer sitting on top of a parser-level flaw: if the server disagrees with the client about where one message ends and the next begins, an attacker can make the server itself write the authenticated mail. Patches shipped within days for the named products, and every mail admin’s December checklist grew a new line item.
What happened
Timo Longhi presented SMTP smuggling at the Chaos Communication Congress in late December 2023, with responsible disclosure already completed: affected vendors (the patch list included multiple enterprise MTAs and security appliances) had shipped fixes through late 2023. The core trick abuses ambiguity in how servers interpret the end-of-data marker — the CR LF . CR LF sequence — when preceded or followed by traffic the client shouldn’t control. A smuggling payload buries a second MAIL FROM / RCPT TO / DATA conversation inside what the receiver parses as two separate, both-legitimate messages.
The killer demonstration targeted inbound mail at major brands: a spoofed message appearing from dhl.com, delivered into the real dhl.com mail environment with SPF and DMARC passes, because the injected conversation originated at their own receiving infrastructure. Comparable proofs followed against several providers as vendors staged patches; some edges of the ecosystem (certain appliances, older MTA versions, downstream relays) stayed exposed for weeks, and detection guidance focused on logging anomalies around end-of-data handling.
The name deliberately echoes HTTP request smuggling: same genus — desync the front-end’s parsing from the back-end’s — different protocol. That framing helped defenders port a decade of request-smuggling intuitions (boundary normalization, strict parsers, rejecting ambiguity) straight into mail infrastructure audits.
How the desync works
In normal SMTP delivery, the client transmits message data and terminates it with a lone period on its own line. The server replies 250 Ok and the conversation moves on. Smuggling exploits implementations that accept non-canonical end-of-data markers — carriage returns, bare line feeds, dot-sequences — as terminators while the next hop uses a stricter definition. The attacker’s extra bytes after the accepted terminator become a fresh SMTP transaction in the eyes of some component downstream: new envelope, new headers, new everything — stamped by infrastructure that trusts its own input.
Two CVEs anchored the disclosure: CVE-2023-51764, the broader MTA-family issue (Postfix shipped the cited fix; other vendors issued advisories against the same technique), and CVE-2023-51765, applying to a mentioned subset of implementations. Exact per-vendor exposure varied — which products were vulnerable to inbound smuggling versus outbound required individual confirmation — so the honest defensive move was technique-level testing: send the probe sequences, see what your own stack accepts, patch accordingly. Hedge vendor lists you see online; the technique outgrows any single CVE pair.
Timeline
| Date | Event |
|---|---|
| 2023 mid-year | Research and coordinated responsible disclosure with affected MTA and appliance vendors proceed privately |
| 2023-12 | Patch wave: advisories and fixes land across mail-infrastructure vendors ahead of public disclosure |
| 2023-12-19 | Public presentation; proof-of-concept spoofed mail shown bypassing SPF/DMARC at a major enterprise (DHL demonstration) |
| 2023-12/2024-01 | Downstream and appliance long tail patches; scanning guidance and detection rules circulate |
| 2024+ | Smuggling-family checks become standard in MTA hardening baselines and mail-security audits |
Roster anchor: public presentation 2023-12-19. Vendor patch dates preceded it individually under embargo — keep any specific vendor chronology hedged to their advisories.
Defensive lessons
- Parser strictness is a security boundary. Accept only canonical end-of-data sequences; every tolerated ambiguity is a potential desync someone will rifle. This is the request-smuggling lesson relearned in mail.
- Authentication confirms the last hop, not the truth. SPF/DMARC passing means your own receiving stack vouches for the message — if the stack was tricked into writing it, the pass is worthless. Validate assumptions beneath your trust layers.
- Patch the technique, not just the CVE. Smuggling families keep recurring across protocols and products; test for the behavior with probe sequences rather than trusting version numbers alone.
- Watch for inbound conversations with unexpected shapes. Multiple MAIL FROM in one connection, odd dot-handling, tiny second messages after large first ones — these log patterns flag smuggling attempts pre-patch.
- Disclosure choreography worked here. Fixes mostly shipped before the talk; celebrate that, and expect the same playbook for the next protocol-parser discovery.
Aftermath in the mail ecosystem
Within weeks, the major Linux distributions and MTA projects had hard guidance out; the technique acquired a permanent place in received wisdom like the null-termination bugs of an earlier era. Mail-filter vendors added smuggling-shaped detection to their appliance signatures, though parsers at the edges — niche relays, ancient groupware, some SaaS inbound bridges — remained quietly exposed long into 2024, and researcher follow-ups periodically resurfaced new variants (the smuggling genus keeps yielding species). The DMARC-industrial complex took a reputational knock that curiously strengthened it: authentication adoption ticked up post-incident as orgs realized defense-in-depth at the mail layer was the only posture that survives parser-level surprises.
Why it still matters in 2026
Business-email-compromise still tops the loss charts, and SMTP smuggling is a BEC accelerant: a spoofed message that passes authentication defeats the training heuristic employees actually use (“check the sender”). Modern mail stacks treat ending conversation boundaries as cryptographic-grade invariants — strict parsing, normalization, and cross-hop consistency checks — because the smuggling family proved cheap analysis tricks could mint authenticated mail out of thin air. If you run anything that speaks SMTP in 2026 — including cloud-run relays you forgot you own — the December 2023 lesson holds: test what your pipeline accepts, not what its changelog claims.
FAQ
Does SMTP smuggling break DMARC permanently?
No — it bypasses it in vulnerable implementations. Patched servers reject the desync sequences, restoring the authentication model. The lesson is layered defense, not abandoning SPF/DKIM/DMARC.
Which products were vulnerable?
The disclosure named a set spanning open-source MTAs and commercial mail security appliances; Postfix’s fix anchored CVE-2023-51764, with the family tracked as CVE-2023-51765 for additional implementations. Exact lists varied by advisory — verify against vendor bulletins and your own testing rather than third-party summaries.
Was it actively exploited before disclosure?
No public evidence of pre-disclosure exploitation in the wild appeared; researchers’ honeypots and vendor telemetry found scanning and probing post-patch. Treat “was I exploited?” as a log-review question, not an assumptions one.
Why “smuggling”?
Borrowed from HTTP request smuggling (2019-era research): both techniques desynchronize two components’ interpretations of message boundaries so one layer accepts traffic the other never sanctioned. Same attack genus, different protocol.
What should a mail admin do today?
Patch MTAs and appliances to current, verify with published probe scripts that your stack rejects non-canonical end-of-data sequences, add the log patterns above to monitoring, and keep DMARC enforcement on — the technique punishes single-layer trust, not the layers themselves.
