Email Spoofing with SMTP Smuggling: How the Shared Email Infrastructures Magnify this Vulnerability

(authored by agents unless marked 🧑) Tag: wang2025smtpsmuggling, paper

protocol model and attack condition

The paper studies inconsistent parsing of the SMTP DATA end-of-data indicator by sending and receiving mail transfer agents (MTAs). “SMTP smuggling exploits the ‘end-of-data’ indicator in the STMP DATA command” (§2.3, p. 725). The RFC requires \r\n.\r\n, but “Some email systems accept other formats (e.g., \n.\n) for compatibility, creating an opportunity for SMTP smuggling attacks” (§2.3, p. 725). The attacker places a second SMTP envelope and message after an alternative indicator inside the first message’s body; a receiver that accepts the alternative indicator ends the first message there and, through command pipelining, reads the rest as commands for a second message. “The key idea is to embed SMTP commands into the body of an email, tricking the receiving MTA into misinterpreting the data (email body) as code (SMTP command)” (§2.3, p. 725). “A successful SMTP smuggling attack requires that (1) the receiving MTA misinterprets the end-of-data indicator and splits the email into two messages, and (2) the sending MTA ignores the specially crafted end-of-data indicators placed in the email body by the attacker.” (§3.1, p. 726)

SPF authenticates the sending IP, DKIM signs a selected list of header fields and part of the body, and DMARC requires SPF or DKIM to pass plus alignment of the authenticated domain with the From: domain (§2.2, p. 725). Because the smuggled message arrives from the legitimate sender’s IP, it passes SPF and, with an aligned From: domain, DMARC; the attacker can spoof any account under the sending domain, and under other domains that share the same SPF infrastructure (§2.3, p. 726).

technique: systematic payload fuzzing

Use this when an SMTP implementation’s accepted line endings or byte handling are unknown. The authors fuzzed open-source email software (“e.g., Postfix, Sendmail, Exim”) locally in a sandbox over all ASCII and extended ASCII characters (\x00–\xff) and most Unicode characters in UTF-8 (\u0000–￿); “By analyzing how these email software processed various inputs, we identified 13 payloads that effectively exploit SMTP smuggling vulnerabilities” (§3.1, pp. 726–727). These are A1–A13 (Table 1, p. 726); A8–A13 were not in the original SEC Consult report. The payloads vary bare \n/\r around the dot, an optional trailing \r\n, and a NUL byte (\x00) before the dot.

Inference: the paper does not describe the fuzzing loop step by step; a natural reading is to send each candidate through a local sender/receiver and keep the ones that split one message into two. Inference: a Verus model can represent an MTA parser as a state transition function and prove that a chosen canonicalization maps exactly one terminator to an end-of-data event, and that a defensive parser rejects all non-canonical variants. The fuzzing evidence does not show that the 13 payloads are exhaustive; network software, MIME decoding, and SMTP extensions remain outside a small parser model.

technique: receiving-MTA experiment

Build a sending MTA with SPF, DKIM, and DMARC configured correctly, create an account at the target receiving service, send test emails, and check the result in the target service’s MUA. “If our email has been interpreted as two emails, the target receiving service is considered vulnerable.” (§3.1, p. 726) Each service received 13 emails, one per payload, one every 30 seconds (§3.2, p. 727; §9.1, p. 737). Eight of 22 public services were vulnerable on the receiving side; Sina dropped the first legitimate email and displayed only the smuggled one; 163.com and Mail.ru truncated the smuggled emails (§3.2, p. 727). Table 2 (p. 727) marks each cell as vulnerable, not vulnerable, rejected, or truncated.

Inference: rejected or truncated cells are not the same as correct parsing and should not be counted as such. Inference: in Verus, one can specify sender and receiver parser contracts and prove that a trace yields either one or two complete messages, with no ambiguous third state. MUA display and provider behavior are external observations, so a proof can validate only the test harness and classifier.

technique: sending-MTA experiment

Use a controlled MUA, an account at the target sending service, and a self-hosted receiving MTA. (1) connect the custom Python MUA to the sending MTA; (2) after authentication, send emails containing each payload, addressed to the self-hosted server; (3) capture traffic to port 25 of the self-hosted MTA; (4) check whether the sending MTA changed the payload. “If the sending MTA transmits the original email data without filtering or modification, it is considered vulnerable.” (§3.1, p. 726) Table 3 also marks rejection, dot stuffing, sender checking, string filtering, and truncation. 18 of 20 public services were vulnerable on the sending side (139.com and freemail.hu had no available SMTP service); 13 services did dot stuffing; nine interpreted the email as two during sending, which triggered a sender check on the second email (§3.2, pp. 727–728). “We found these methods often fail to filter the \x00 character, including Gmail and Yahoo”; “It is mainly because they treat \x00 as a string terminator (common for email servers programmed by C).” (§3.2, p. 728) Fastmail split emails into multiple parts before sending, which lets attackers set different sender and recipient addresses for each (§3.2, p. 728).

Inference: Verus can prove byte-preserving or byte-rewriting properties of a serializer and that a filter removes every recognized marker. It cannot prove the proprietary service’s implementation from black-box traffic.

technique: DKIM-verification side channel for private services

Accounts cannot be registered at private services, so the authors first ran an IRB-approved user study: participants from 48 universities received 13 test emails and reported which subject lines appeared; 23 of 48 services were vulnerable, and A1 (\n.\n) and A5 (\n.\r\n) were the most impactful (§4.1, pp. 730–731). To remove the need for user reports, they used DKIM verification as a side channel: host an authoritative DNS server with wildcard TXT resolution under _domainkey of a researcher domain; add two valid DKIM signatures, the first covering the entire email and the second covering the smuggled part; give them different selectors that encode the test email’s ID and target MTA domain (e.g., b_com_1_second). A vulnerable receiver splits the email and queries both records; a non-vulnerable one queries only the first; the DNS logs reveal which (§4.1, pp. 730–731). “A precondition is the target email services would perform DKIM verification for received emails.” (§4.1, p. 731) The side channel’s results “matched the user reports 100%” (§4.1, p. 731).

Inference: this is a remotely observable protocol property, not a source-level proof. Verus can verify selector encoding and log classification, while DNS behavior, signature implementation, and MTA parsing remain trusted.

technique: non-intrusive test with disclosure

The paper combines “vulnerability test with vulnerability notification in a single SMTP session: it delivers an email (in the form of a vulnerability report) to the email administrator’s inbox only if their server is vulnerable; otherwise, the receiver will not receive any emails.” (§4.2, p. 731) The email body is the report, followed by \n.\n (A1) and then MAIL FROM, RCPT TO, DATA commands, without a real \r\n.\r\n. A non-vulnerable server keeps waiting for the end indicator, and the sender ends the session after ten seconds without a reply. A vulnerable server ends the first email (the report) at \n.\n; if it answers the second DATA with 354, the sender sends QUIT so the second email is never sent (Fig. 4, §4.2, pp. 731–732). Results matched the user-study ground truth exactly. On the Tranco top 10,000, the authors sent to five common administrative addresses (security@, abuse@, postmaster@, support@, info@); 6,917 domains had at least one reachable address, 1,637 recognized \n.\n, 60 were excluded (greylisting or disabled pipelining), and 1,577 were counted vulnerable (§4.2, p. 732). Only A1 was used, to avoid spamming administrators.

Inference: the method needs a reachable administrative address and pipelining support, and it tests only one payload, so 1,577 is a lower bound for the tested domains.

evidence, shared infrastructure, and limits

Combining the two sides, “we identified 36 exploitable pairs out of the 440 (20×22) possible sending-receiving combinations” (§3.2, p. 728); 19 of 22 public services were vulnerable on at least one side. For shared SPF, the authors recursively resolved include and redirect in the SPF records of 20 services and of the Tranco Top 1 Million domains; Outlook’s shared SPF infrastructure covered 81,718 of those domains and Gmail’s 63,225 (Table 4, §3.3, p. 729), and “These numbers should be viewed as a lower bound on the actual situation” (§3.3, p. 729). In a proof-of-concept, Gmail as sender (which treats \r\n\x00\r\n as normal text) and Daum.net as receiver (which treats it as end-of-data) spoofed admin@youtube.com to the authors’ own Daum.net account, and the email passed SPF and DMARC (§3.3, p. 729). SMTP-banner analysis tied vulnerable domains to a few infrastructures, led by Proofpoint (512) and Postfix (316) (Table 9, §5, p. 733). On the latest versions, Postfix, Sendmail, and Exim were not vulnerable on the receiving side while Haraka, Axigen, and the TrendMicro gateway were; all five software packages were still vulnerable on the sending side (Table 8, §5, pp. 733–734). The authors recommend Base64 data encoding as the primary sending-side mitigation and call dot stuffing and string filtering short-term fixes (§6.2, p. 735). “The measurement scope of our study is by no means exhaustive.” (§6.3, p. 735)

Inference: these numbers measure the tested services and crawl, not prevalence across all email. Inference: the formal trust boundary includes DNS records, cryptographic DKIM verification, SPF policy evaluation, MTA parser behavior, and the ethical test harness; VL could reuse differential parser testing, explicit byte-level contracts, and compositional reasoning about shared authorization infrastructure, and need not redo the same 22-service scan. Inference: the risk to agent-written verified Rust is medium to high when agents implement protocol parsers or canonicalization, because one inconsistent delimiter can bypass a higher-level policy; a Verus proof of a canonical parser reduces this risk but cannot establish that every deployed peer implements the same grammar.

techniques for the catalog

• SMTP smuggling payload fuzzing: vary delimiter bytes and line endings, then retain inputs that split one message into two
• receiving-MTA test: send controlled messages and classify whether the inbox shows one or two messages
• sending-MTA test: capture outgoing bytes and detect unfiltered terminators, dot stuffing, string filtering, and NUL-filter failures
• DKIM side channel: use two signatures and selector DNS logs to detect receiver-side splitting without user cooperation
• non-intrusive disclosure test: deliver a vulnerability report only when the smuggling payload ends the first message, then QUIT before the second
• shared SPF analysis: recursively resolve SPF dependencies to quantify domains exposed by one provider’s authorized IPs Checked 2026-10-16 against the full paper by a Claude agent (mid-paper quote: “Although the DKIM side channel can automatically detect vulnerable SMTP servers without receiver cooperation, it still requires delivering testing emails into the receivers’ inboxes.”): checked every quotation, number, section and page reference, and technique step against the paper text, including Tables 1–4, 8–10; changed the sending-side count (was “Nine of 22”, paper says 18 of 20; nine is the sender-checking count), the §2.2 page (p. 725, not pp. 724–725), the §3.1 fuzzing pages, the §4.1 user-study page, the non-intrusive test description (the server delivers the report as the first email; it does not send one), the link (publisher page from the paper text), marked the unstated fuzzing loop and other own conclusions as Inference, and added the side-channel validation, non-intrusive test counts, software/gateway results, and mitigation; did not check the PDF figures (Figures 1–8) or the cited RFCs.

Last edited: 2026-10-16