Take the idea of HTTP request smuggling, and apply it to SMTP and you’ve got an idea of what is going on with this awesome research out of Sec-Consult.com.

Kinda like HTTP where you often have a request passing through multiple servers before it reaches the actual backend server. With SMTP you have the idea of a outbound SMTP server. This is the server that would be connected to to send a message in the first place. You’ve connect to the outbound SMTP service for your mail provider. Your mail client gives it whatever SMTP commands to authenticate and send the mail. And then that provider will connect to the recipients inbound SMTP server passing along at least the data segment from your original message.

Also like HTTP, SMTP packets are split into two section, the SMTP commands first, followed by message data. Lets take a quick look at an example SMTP message:

ehlo sender.exmaple\r\n
mail FROM:<user@sender.example>\r\n
rcpt TO:<user@receiver.example>\r\n
data\r\n
From: user@sender.example\r\n
To: user@receiver.example\r\n
Subject: Example\r\n
\r\n
lorem ipsum
\r\n.\r\n
quit

Whats important here is that data segment, marked with the data\r\n at the start, and then the end-of-data sequence \r\n.\r\n. This is one way the message contents can be encoded and sent over SMTP. While the \r\n.\r\n sequence is how the end of the data is supposed to be indicated, not all servers are consistent in what they accept as an end-of-data sequence. If there were any sequences that an outbound server could be made to send, that an inbound server would accept as an end-of-data sequence. Then one could craft a message with more SMTP commands after the fake end-of-data sequence that will be read as SMTP commands instead of being part of the data.

As you might guess, such sequences were discovered. Namely, the research starts with the \n.\r\n sequence. Finding that many outbound servers would allow that in the data, and some inbound servers would treat it as the end-of-data sequence and start processing the rest of the message data as SMTP commands. Allowing a SMTP commands to be used to smuggle in a second email to be sent.

As these second smuggled message, would be coming from a legitimate mail server it would be able to spoof the email as having been sent legitimately, getting past SPF checks (checks the server sending the email is authorized to do so for a given domain). They also found other, more exotic end-of-data sequences (like \r.\r) would be accepted like Cisco mail servers (as used by Amazon, PayPal, the IRS and other big names) and could easily be sent through most outbound servers.

On a whole I think this is some really cool research, and given the number of SMTP implementations out there I’d be surprised if this is the end of parser differentials creating security issues in SMTP.