SMTP Smuggling — End-of-DATA Discrepancy Spoofing

Even when your domain publishes SPF, DKIM and a DMARC policy of reject, a forged message using your domain can pass all three checks at a receiver whose mail server is vulnerable to SMTP smuggling. SMTP smuggling is a spoofing attack. It exploits the fact that two mail transfer agents (MTAs) in a mail path can disagree about where the DATA of a message ends.

The base protocol (RFC 5321) ends DATA with exactly <CR><LF>.<CR><LF>: a dot alone on a line, framed by CRLF. For decades, servers have also tolerated non-standard variants with a bare <LF>, such as <LF>.<LF>, <LF>.<CR><LF> and <CR>.<CR>. This leniency dates from Sendmail, and Postfix, Exim and others copied it for interoperability.

When the sending (outbound) server and the receiving (inbound) server tolerate different sets of these variants, an attacker can inject a crafted line-ending sequence into a message body. The receiver then believes DATA has ended partway through the message, and treats the bytes that follow as new SMTP commands. They form a second MAIL FROM / RCPT TO / DATA transaction, that is, a second, fully spoofed message "smuggled" inside one legitimate SMTP transaction.

SEC Consult disclosed the attack publicly on 18 December 2023. It is one of the more serious email spoofing techniques of recent years because of what it defeats: it makes a forged message pass SPF, DKIM and DMARC. It is mainly a vulnerability of receivers, and the fix belongs in the inbound MTA. Senders and ESPs still need to understand it, because a vulnerable receiver silently undermines the DMARC protection that senders rely on to defend their domains. The attack does not weaken any authentication record you publish. It defeats the enforcement of those records at a vulnerable receiving server.

The parsing discrepancy

There are two roles and two ways to fail, and the attack needs one failure of each kind:

Neither behavior can be exploited on its own. The outbound server must let the unusual sequence through onto the wire, and the receiving server must accept it as the end of DATA. An attacker who controls a lenient outbound service, or has a free or compromised account on one, and who targets a lenient inbound service, can exploit the gap between them.

Anatomy of a smuggled transaction

An authenticated attacker submits one message through the outbound service. The visible envelope and headers use the attacker's own legitimate, throwaway address, so the submission is authorized. Inside the DATA payload, the attacker plants:

...legitimate-looking body...
<LF>.<LF>                          ← smuggled end-of-DATA (receiver honors it)
MAIL FROM:<admin@victim-domain.example>
RCPT TO:<target@receiver.example>
DATA
From: admin@victim-domain.example
Subject: (spoofed message)
...attacker payload...
<CR><LF>.<CR><LF>                  ← real end-of-DATA

The vulnerable outbound service sends all of this as the body of the first message, because it did not treat <LF>.<LF> as the end of DATA. The vulnerable inbound service reads the same bytes, but does treat <LF>.<LF> as the end of the first message. It then interprets MAIL FROM / RCPT TO / DATA as a brand-new transaction. The receiver has now accepted a second message whose From: is admin@victim-domain.example, delivered over the outbound provider's own trusted, authenticated connection.

BDAT / CHUNKING (RFC 3030) offers a related route. BDAT frames content with an explicit count of octets instead of scanning for <CRLF>.<CRLF>, so it allows command pipelining that the DATA path forbids. Faulty BDAT handling has been a separate smuggling route on the inbound side. This is the interoperability warning noted in the CHUNKING section of the ESMTP extensions reference.

Why it bypasses SPF, DKIM, and DMARC

The smuggled message is not authenticated in its own right. It inherits the authentication of the outer session. Each mechanism fails for a different reason:

The result: admin@outlook.com, admin@microsoft.com, or any address at ~1.35 million domains hosted by GMX and Ionos could be spoofed with a passing DMARC result at a vulnerable receiver. A domain owner who has done everything right (SPF, DKIM, DMARC at p=reject) gets no protection at a receiver that ends DATA leniently, because the forgery never had to defeat the records. It arrived inside a trusted session.

Compare this with DKIM replay. Replay resends a genuinely signed message unchanged, to spend a sender's reputation. Smuggling creates a new message that borrows the authentication of a session. Both defeat the simple reasoning that a message is trustworthy because DMARC passed, from opposite directions.

The December 2023 disclosure: affected parties

SEC Consult (Timo Longin) demonstrated the attack against major production infrastructure. The difference between the outbound role (failing to clean up the sequence) and the inbound role (accepting unusual sequences) matters, because a provider could be exploitable in one role, the other, or both.

Disclosure timeline: first discoveries in June 2023, notifications to vendors in late July 2023, patches from GMX (Aug) and Microsoft (Oct), and public disclosure on 18 Dec 2023.

CVEs were assigned to the open-source MTAs:

Mitigations

The lasting fix is strict enforcement of the end of DATA at the receiver: accept only <CR><LF>.<CR><LF>, and neutralize bare newlines before they can be read as the end of DATA. Cleaning up on the outbound side, by normalizing a bare <LF> to <CR><LF> before sending, closes the other half. The large providers deployed exactly this on their servers.

Postfix (receiver-side)

Postfix's guidance (postfix.org/smtp-smuggling.html) offers a short-term workaround and a long-term fix. Parameter defaults depend on the Postfix release.

Long-term fix: handling of bare newlines (Postfix 3.8.5 / 3.7.10 / 3.6.14 / 3.5.24 and later):

smtpd_forbid_bare_newline = normalize
smtpd_forbid_bare_newline_exclusions = $mynetworks

normalize accepts a bare <LF> from the client but processes it as if <CR><LF> had been sent, while still requiring the standard <CR><LF>.<CR><LF> to end DATA. This defeats <LF>.<LF> smuggling without breaking older clients. The stricter reject setting refuses any bare newline outright, but may reject some legitimate mail. The $mynetworks exclusion spares trusted internal senders, such as local scripts. Later Postfix releases moved the default toward enforcement.

Short-term workaround: block the route through pipelining and CHUNKING:

smtpd_data_restrictions = reject_unauth_pipelining
smtpd_discard_ehlo_keywords = chunking, silent-discard

or, on Postfix 3.8.1+:

smtpd_forbid_unauth_pipelining = yes
smtpd_discard_ehlo_keywords = chunking, silent-discard

smtpd_forbid_unauth_pipelining is enabled by default in Postfix 3.9+. In 3.8.1 / 3.7.6 / 3.6.10 / 3.5.20 it shipped disabled, for compatibility. Discarding the chunking EHLO keyword withdraws BDAT, which removes the route through BDAT command pipelining. The cost is losing the benefits BDAT would otherwise give for throughput and large messages.

Cisco Secure Email (receiver-side)

Change how the listener handles non-standard line endings. The vulnerable "Clean" behavior rewrites a bare CR or LF into CRLF, and can create an exploitable sequence for the backend server. Switch it to "Allow", which passes the bytes through unchanged, so a strict backend that requires <CR><LF>.<CR><LF> never sees a false end of DATA. The vulnerable value was the default and vendor support was lacking at first, so operators had to make this change themselves.

General receiver checklist

• Enforce <CR><LF>.<CR><LF> as the only end of DATA. Reject or normalize a bare <CR> or <LF>.
• Forbid unauthenticated command pipelining. Treat MAIL FROM, RCPT TO or DATA appearing inside DATA as a sign of attack.
• Withdraw BDAT and CHUNKING on untrusted inbound listeners, or audit them carefully.
• Clean up outbound mail too. Normalize bare newlines so that your outbound path can never send the building block of a smuggling attack to a receiver further along.
• Keep MTA software up to date (past the CVE-2023-5176x fixes).

What it means for senders and ESPs

• You cannot fix this by changing your own DNS records. No SPF, DKIM or DMARC configuration stops smuggling, because it defeats enforcement, not publication. p=reject is still worth having. It protects you at every receiver that is patched, which since 2023 covers the large majority of mailbox-provider volume.
• If you are an ESP running inbound MTAs (intake of feedback loop reports, the abuse@ and postmaster@ role addresses, bounce processors, MX for customer domains), you are a receiver, and the receiver-side fix is yours: strict enforcement of the end of DATA, current MTA builds, and careful control of where BDAT is offered. See abuse desk and outbound monitoring for where these listeners are.
• If you are an ESP running outbound MTAs, make sure your submission path normalizes bare newlines. Otherwise a compromised or hostile customer could use your trusted IP addresses to smuggle spoofed mail from a third party's domain into a vulnerable receiver, which is exactly the abuse the large providers had to patch. This belongs with the hygiene of customer domain authentication, and with the wider forms of spoofing abuse in the email abuse taxonomy.
• Understand the risk that remains in reporting. A customer or brand you protect may see a report of a spoofed message that "passed DMARC", and the explanation may be a vulnerable receiver rather than a flaw in their setup. Being able to name SMTP smuggling, and point to the receiver-side fix, is the difference between a correct diagnosis and a long, fruitless search through the sender's DNS.

Related articles

• DMARC (introduction), on the alignment logic that smuggling borrows to pass
• DKIM Replay, the other major attack that defeats the assumption that a DMARC pass means a message can be trusted
• SMTP (RFC 5321), which defines <CR><LF>.<CR><LF> as the end of DATA
• ESMTP Extensions, on PIPELINING, CHUNKING and BDAT, which the workarounds restrict
• SPF and DKIM, neither of which inspects the From: header on its own