SMTP smuggling is a class of attack on mail delivery in which one server in a chain and another server disagree about where a message begins and ends. When the two servers parse the same byte stream differently, one of them may treat part of a message as a separate message. The result can be a message that bypasses checks applied to the first one. This article describes the idea at a high level and explains why strict parsing is the main defense. It does not describe how to construct the input.
The core problem: framing
SMTP sends a message as a stream of lines. The end of the message body is marked by a line containing only a period. The protocol also has a dot-stuffing rule, so lines that begin with a period are escaped. Everything depends on both sides agreeing on what counts as a line break and what counts as the terminator. If they disagree about the framing, the boundaries of the message also differ.
Standards say that lines end with a carriage return and a line feed. Real software has sometimes accepted a bare line feed, or handled a bare carriage return differently. Each of those choices is reasonable on its own, but they are not all the same. When two servers in a chain make different choices, a single message can have two different interpretations.
What goes wrong in a chain
Consider a message passing through two servers. The first, a front-end, accepts mail from the internet and checks it, perhaps for authentication, content or policy. The second, a back-end, delivers it to a mailbox. If the front-end thinks the message ends at one point and the back-end thinks it ends at a different point, the back-end may process the remainder of the stream as a new message. That new message was never checked by the front-end. It may carry different headers, including sender information, and the back-end may accept it.
This is the sense in which the message is smuggled. The checks happened, but to a different message than the one that was delivered.
Why strict parsing matters
The defense is for every server in the chain to agree on the same framing, and the simplest way to achieve that is to refuse input that is ambiguous. A strict server:
- Rejects bare line feeds and bare carriage returns, instead of guessing what they mean.
- Requires the exact terminator sequence and does not accept near-matches.
- Rejects a message whose framing is inconsistent with the protocol, rather than trying to recover.
- Uses the same rules on every hop, so that an internal relay does not accept what an edge server would refuse.
Lenient parsing is attractive because it accepts more mail from imperfect senders. But leniency is a liability when a second component makes a different choice, because the disagreement is where attackers operate. Tolerating a malformed line is a small convenience that becomes a security risk the moment another system reads it differently.
The general lesson
SMTP smuggling is one instance of a broader pattern: when a system depends on checking data before passing it on, the checker and the consumer must parse the data identically. The same reasoning applies to HTTP request smuggling, header parsing in web frameworks, and other protocols with layered components. Strict, consistent parsing across a whole path is more reliable than checks that are perfect on one component and lenient on the next.
Practical steps for operators
- Keep MTA software up to date. Vendors have released fixes for parsing behavior, and the fixes matter most on the edge.
- Configure strict line-ending handling where your MTA offers the option, and test that legitimate senders still work.
- Make internal hops as strict as the edge. A relay that accepts what the edge rejects is the weak point.
- Review logs for unusual message framing, such as messages with embedded terminators or unexpected line endings.
- Check the vendor advisories for your mail software, and apply them on the normal patch schedule.
What senders and users can do
Most people do not control SMTP parsing, and nothing in an ordinary mail client exposes the framing. The practical effects are in what the provider does. Authentication results and DMARC are only useful if the checked message is the one delivered, so providers that run strict parsing make those signals more trustworthy. If you are choosing a provider, ask how they handle malformed input and whether they apply the same rules to all hops. The security checklist covers the account-side settings you can control.
ITProMail runs its own mail infrastructure, and its handling of malformed input is part of its operational security. For a concrete look at the authentication records that depend on correct delivery, read SPF, DKIM and DMARC explained, and for the questions to ask any provider, see the FAQ.