Script to help analyze mail servers for SMTP Smuggling vulnerabilities.
smtpsmug allows sending mails to an smtp server and ending it with various malformed
end of data symbol. This tests whether servers are affected by SMTP Smuggling
vulnerabilities. Please consider this preliminary and work in progress, I am still
trying to fully understand the issue myself.
By default, smtpsmug will send a test mail ending with a '\n.\n' symbol (Unix newlines
instead of Windows '\r\n' newlines). It supports multiple other malformed endings. Use
--list-tests to show them, --test [testname] to select one.
To test the postfix mitigation, there is now a pipelining test. (May be unstable.)
There are multiple behaviors of mail servers that enable the vulnerability:
-
Mail servers accept malformed endings. This is in all cases a bug and a violation of RFC 5321, section 4.4.1.
-
Mail servers accept malformed endings within mails and forward them to other mail servers. To test this, you need to monitor the receiving side. (The fake-mail-server by Damian Poddebniak, written for our previous STARTTLS research, can be used for this.)
-
I believe (but am not 100% sure) that mail servers should never accept any solo '\r' or '\n' characters and always answer with an error if they see them not in the '\r\n' combination. It appears some mail servers will accept such characters, but transform them to '\r\n', and safely escape dots via dot stuffing. Rejecting them seems safer. RFC 5321, section 3.2.8 states: "SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a sequence." This appears clear that conforming clients must not send such stray characters, but it does not explicitly say what receiving servers should do in such a case.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent