1

We are planning to create a rule in Proofpoint to enforce TLS on all outgoing email. I need to test that the rule is working and emails are bouncing if the recipient SMTP server does not support TLS.

The question is, where can I find or how can I create an SMTP server that doesn't support TLS? Or an SMTP server where I can specifically disable TLS?

I looked everywhere, but I couldn't find any.

closed as off-topic by Steffen Ullrich, Xander, forest, Adonalsium, Jeroen - IT Nerdbox Apr 17 at 6:51

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – Steffen Ullrich, Xander, forest, Adonalsium, Jeroen - IT Nerdbox
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    "where can I find or how can I create an SMTP server that doesn't support TLS" - you essentially asking to setup a SMTP server with no TLS support. This is not an actual security question. But there are several well-documented SMTP servers (like Postfix) you can install yourself. – Steffen Ullrich Apr 10 at 10:15
1

Within Proofpoint you should be able to set up a manual mail route (to override DNS/MX) to some external domain so that it uses only SMTP rather than ESMTP. You do this by prefixing the destination with "SMTP:", e.g.

 gmail.com → SMTP:gmail-smtp-in.l.google.com.

This will cause your side to issue an old SMTP "HELO" rather than a new "EHLO" and STARTTLS should not be possible. (This requires both sides to be protocol compliant, it is possible to attempt STARTTLS over plain SMTP in some cases.) If you have an enforced TLS rule for that domain, outbound email should fail.

Or, a network solution, you could use one of many TLS stripping/MITM tools (e.g. striptls), this performs the equivalent of the above by intercepting traffic to prevent STARTTLS being advertised/detected/enabled.

Otherwise, with any modern SMTP server supporting STARTTLS, if you configure only a set of ciphers that require RSA authentication (openssl ciphers -v aRSA) but do not configure a key and certificate then STARTTLS will not be supported.


There's a subtle distinction between TLS and STARTTLS, the latter is performed as an in-protocol upgrade: within the SMTP exchange the "STARTTLS" verb is issued and then TLS is negotiated (which is why it has security limitations).

With "regular" TLS the TLS happens first, and can be used for any protocol without first extending it to support that type of upgrade. There is was an old standard for SMTP with TLS, ssmtp subsequently smtps — it never caught on (just like HTTP with STARTTLS). SMTPS on TCP/465 has since been resurrected in RFC8314, but as Steffen notes this is not for MTA-to-MTA, it's only for MUA (client) submission.

  • 1
    "There is a standard for SMTP with TLS, SMTPS on TCP/465, it never caught on..." - this is not really true. It is actually widely supported for the first hop when the mail client submits the mail to the pre-configured server. It is not supported for MTA to MTA communication though because the next MTA is determined by a DNS MX lookup and an MX is by definition on port 25 with protocol SMTP. No alternative port or protocol can be given as MX result. – Steffen Ullrich Apr 10 at 11:05
0

SMTP is a really simple protocol that you can test by hand! If you have a tool like telnet or netcat handy, you can just type the commands manually. If you are on Windows, you can install the telnet client from the "Install or remove Windows components" menu. If you are on Linux, I would recommend using netcat -vC (the v option for verbosity and the C option for CRLF line endings).

First, open a connection:

nc -vC mail.example.com 25
  or
telnet mail.example.com 25

Then, try sending an email without using encryption:

EHLO test
MAIL FROM:<someone@example.com>
RCPT TO:<yourself@example.com>
DATA
Test
.
QUIT

After the . on an line by itself, you should get the message that the mail is queued for delivery. Note that you will want to replace @example.com with your own domain, because the server will almost certainly not allow deliveries from an external domain to an external domain (this would be an open relay).

If the email is accepted, then clearly no encryption is enforced. If it is not allowed, you will get an error message somewhere in this process.


Alternatively, you could use an external service to test it. Search online for "smtp tester" or "starttls tester" and you should find some services. I found three that look promising in the top few results, but they do not explicitly claim to test enforcement of TLS, so I'm not sure if that specific test also exists.

  • This only checks if the server supports sending mails without TLS. The server might still supporting sending mails over TLS too. But the OP is specifically asking for servers which don't support TLS. To check if the server does not support TLS one should try STARTTLS command. – Steffen Ullrich Apr 10 at 10:18
  • @SteffenUllrich I don't understand your comment. "This only checks ... without TLS." That's what OP asks, right? They want to check whether their proofpoint mitm thingy forces TLS, so if you can do non-TLS deliveries, then it doesn't enforce. "The server might support sending over TLS too." Could it be that you misunderstand me and assume this would be sent to the internal mail server, which might indeed forward it as TLS and pass proofpoint, whereas I meant to test going through proofpoint using telnet/netcat and see if proofpoint stops the connection? – Luc Apr 10 at 14:21
  • In my understanding the OP tries to configure Proofpoint in a way that it will not deliver mail to MTA without TLS. It does not matter for this if the MTA supports both plain and TLS (as most will do), all what matters is that it will not talk plain to the MTA. In order to verify that this setting is correct the OP wants to try to deliver a mail to a MTA which cannot do TLS with the expectation that this delivery should fail. But you check only if the MTA can speak plain, not if the MTA cannot speak TLS. – Steffen Ullrich Apr 10 at 14:37
  • @SteffenUllrich Ah, now I understand what you meant. If that is indeed what OP meant, my answer is indeed not applicable. I guess he'll let us know (either through commenting or accepting the other answer)... – Luc Apr 10 at 14:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.