SMTP Smuggling

Reading time: 7 minutes

Basic Information

This type of vulnerability was originally discovered in this post were it's explained that It's possible to exploit discrepancies in how the SMTP protocol is interpreted when finalising an email, allowing an attacker to smuggle more emails in the body of the legit one, allowing to impersonate other users of the affected domain (such as admin@outlook.com) bypassing defenses such as SPF.

Why

This is because in the SMTP protocol, the data of the message to be sent in the email is controlled by a user (attacker) which could send specially crafted data abusing differences in parsers that will smuggle extra emails in the receptor. Take a look to this illustrated example from the original post:

How

In order to exploit this vulnerability an attacker needs to send some data that the Outbound SMPT server thinks that it's just 1 email but the Inbound SMTP server thinks that there are several emails.

The researchers discovered that different Inboud servers considers different characters as the end of the data of the email message that Outbound servers doesn't.
For example, a regular end of the data is \r\n.\r. But if the Inbound SMTP server also supports \n., an attacker could just add that data in his email and start indicating the SMTP commands of a new new ones to smuggle it just like in the previous image.

Ofc, this could only work if the Outbound SMTP server doesn't also treat this data as the end of the message data, because in that case it will see 2 emails instead of just 1, so at the end this is the desynchronization that is being abused in this vulnerability.

Potential desynchronization data:

• \n.
• \n.\r

Also note that the SPF is bypassed because if you smuggle an email from admin@outlook.com from an email from user@outlook.com, the sender is still outlook.com.

Attacker’s checklist (what conditions must hold?)

To successfully smuggle a second email, you typically need:

• An outbound server A you can send through (often with valid creds) that will forward a non‑standard end‑of‑DATA sequence unchanged. Many services historically forwarded variants like \n.\r\n or \n.\n.
• A receiving server B that will interpret that non‑standard sequence as end‑of‑DATA and then parse whatever follows as new SMTP commands (MAIL/RCPT/DATA...).
• Outbound must actually send with DATA (not BDAT). If A supports CHUNKING/BDAT, smuggling only works if it falls back to DATA (e.g., B doesn’t advertise CHUNKING), otherwise length‑framed BDAT prevents ambiguity.
• PIPELINING isn’t required but helps hiding the injected commands in a single TCP write so intermediate devices don’t resynchronize.

Common end‑of‑DATA variants worth testing (receiver-dependent):

• \n.\n
• \n.\r\n
• \r.\r\n
• \r\n.\r (bare CR at end)

Note: What works is the intersection of “what A forwards” ∩ “what B accepts”.

Manual exploitation example (single session)

The following shows the idea using a raw STARTTLS SMTP session. After the first DATA block we insert a non‑standard terminator, then another SMTP dialog that the receiving server may treat as a new message.

$ openssl s_client -starttls smtp -crlf -connect smtp.example.com:587
EHLO a.example
AUTH PLAIN <base64(\0user@example.com\0password)>
MAIL FROM:<user@example.com>
RCPT TO:<victim@target.com>
DATA
From: User <user@example.com>
To: victim <victim@target.com>
Subject: legit

hello A
\n.\r\nMAIL FROM:<admin@target.com>
RCPT TO:<victim@target.com>
DATA
From: Admin <admin@target.com>
To: victim <victim@target.com>
Subject: smuggled

hello B
\r\n.\r\n

Tip: When testing interactively, ensure -crlf is used so OpenSSL preserves CRLF in what you type.

Automation and scanners

• hannob/smtpsmug: send a message ending with multiple malformed end‑of‑DATA sequences to see what a receiver accepts.
  • Example: ./smtpsmug -s mail.target.com -p 25 -t victim@target.com
• The‑Login/SMTP‑Smuggling‑Tools: scanner for both inbound and outbound sides plus an analysis SMTP server to see exactly which sequences survive a sender.
  • Inbound quick check: python3 smtp_smuggling_scanner.py victim@target.com
  • Outbound via a relay: python3 smtp_smuggling_scanner.py YOUR@ANALYSIS.DOMAIN --outbound-smtp-server smtp.relay.com --port 587 --starttls --sender-address you@relay.com --username you@relay.com --password '...'

These tools help you map the A→B pairs where smuggling actually works.

CHUNKING/BDAT vs DATA

• DATA uses a sentinel terminator <CR><LF>.<CR><LF>; any ambiguity in how CR/LF are normalized or dot‑stuffed leads to desync.
• CHUNKING (BDAT) frames the body with an exact byte length and therefore prevents classic smuggling. However, if the sender falls back to DATA (because the receiver doesn’t advertise CHUNKING), classic smuggling becomes possible again.

Notes on affected software and fixes (for targeting)

• Postfix: prior to 3.9 the default tolerated bare LFs; from 3.5.23/3.6.13/3.7.9/3.8.4 admins can enable smtpd_forbid_bare_newline. Current recommendation is smtpd_forbid_bare_newline = normalize (3.8.5+/3.7.10+/3.6.14+/3.5.24+) or set to reject for strict RFC enforcement.
• Exim: fixed in 4.97.1 (and later) for variants relying on mixed end‑of‑DATA sequences when DATA is used. Older 4.97/4.96 may be exploitable depending on PIPELINING/CHUNKING.
• Sendmail: fixed in 8.18; older 8.17.x accepted some non‑standard terminators.
• Various libraries/servers (e.g., aiosmtpd before 1.4.5, some vendor gateways, and specific SaaS relays) had similar issues; modern versions tend to accept DATA only with strict <CR><LF>.<CR><LF>.

Use the scanners above to verify current behavior; many vendors changed defaults in early 2024–2025.

Tips for red team ops

• Favor large commodity senders for A (historically Exchange Online, shared hosters, etc.). If they still forward some non‑standard EOM and they’re in the victim’s SPF, your smuggled MAIL FROM will inherit their reputation.
• Enumerate B’s SMTP extensions: EHLO banner for PIPELINING/CHUNKING; if CHUNKING is missing you have a better chance from BDAT‑first senders. Combine with malformed EOMs to probe acceptance.
• Watch headers: the smuggled message will usually create a separate Received chain starting at B. DMARC will often pass because MAIL FROM aligns with A’s IP space.

References

• https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
• https://www.postfix.org/smtp-smuggling.html