1

This article tells us that there are two types of STARTTLS: Opportunistic (i.e. optional STARTTLS) STARTTLS and Enforced STARTTLS, which works by the doctrine of "Encrypted connection or drop connection".

We can use checktls.com/TestReceiver to check if the mail server supports STARTTLS.

But how do I find out if it enforces it? I basically need to check that the server, when the other side does not support STARTTLS, drops the email rather than downgrading to unencrypted transfer.

I have to do Black Box penetration/security test of this mail server, so I do not have access to inside configuration of the server. I am also a newbie and am just studying, learning and doing, as we don't live in an ideal world, where i would have the luxury of studying just this topic for months and then do it.

EDIT: There is a confusion about whether I am talking about inbound or outbound emails. I am sorry, actually I am new to this, so I wasn't clear enough in my questioning.

I am talking about both inbound and outbound emails. The problem is that the owner of the mail server thinks/knows that their data is being sniffed. So what we need is that any email going out of this mail server, or any email that is coming into this mail server, should not be sniffed/caught in plaintext under any circumstance.

Say this mail server is webmail.abc.com. So what we want is that any emails originating from users of that mail server, or any emails that are intended for users of that mail server, must never get UNencrypted under any circumstance.

user75058
  • 11
  • 2
  • 1
    Setup a mail domain with a server without TLS support. Try to deliver a mail to this domain through your server. If it gets received then TLS was obviously optional. – Steffen Ullrich Jul 13 '21 at 19:35
  • OP, WRT 'I basically need to check that the server, when the other side does not support STARTTLS, drops the email rather than downgrading to unencrypted transfer', please see https://www.ultrasmtp.com/images/smtp.png. Which component in this figure are you referring to when you say 'the server' and which component are you referring to when you say 'other side'? – mti2935 Jul 13 '21 at 20:32
  • @mti2935 "Sender's Outgoing SMTP Server" is 'the server' and 'the other side' is 'Recipient's Incoming MX Server'. The arrows can be reversed. Because I am talking about both inbound and outbound emails from the server under consideration. This server has 995, 993, 587, 443, 143, 110, 80, 25 ports open. This means it has all SMTP, IMAP and POP services running on it. It lies on webmail.something.com and from that I know its IP. That's all info I have about it, for my black box security test. – user75058 Jul 14 '21 at 07:36
  • OP, OK, this is helpful. In general, whenever a message is handed off from one MUA or MTA to another MUA ot MTA, one is acting as a client and the other is acting as a server. The one acting as a client makes a connection to the one acting as a server (which is listening for incoming connections). If it is the one that is acting as a client that you are testing, then the comment above by @SteffenUllrich applies. If it is the one that is acting as a server that you are testing, then my answer below applies. – mti2935 Jul 14 '21 at 14:51

3 Answers3

1

You can determine whether or not an SMTP server enforces STARTTLS using telnet.

Here is an example using smtp.gmail.com, which does enforce STARTTLS.

First, open a connection to smtp.gmail.com on port 587 using telnet:

telnet smtp.gmail.com 587

smtp.gmail.com responds with:

Escape character is '^]'.
220 smtp.gmail.com ESMTP 6sm4582570qkv.115 - gsmtp

Next, send a ehlo command:

ehlo test.com

smtp.gmail.com responds with:

250-smtp.gmail.com at your service, [2601:44:1:93d0:8d8f:4473:96a4:f2a3]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

At this point, a client that wants to commence using STARTTLS would send STARTTLS. A client that does not want to commence using STARTTLS would proceed with the standard SMTP protocol, which in most cases would be the MAIL FROM command. Let's see what happens if we proceed with MAIL FROM without sending the STARTTLS command:

MAIL FROM: <test@test.com>

smtp.gmail.com responds with:

530 5.7.0 Must issue a STARTTLS command first. 6sm4582570qkv.115 - gsmtp

The above 530 response shows that smtp.gmail.com enforces STARTTLS. If the SMTP server did not enforce STARTTLS, then is would respond with a 2xx response code, indicating that it accepted the MAIL FROM command.

mti2935
  • 19,868
  • 2
  • 45
  • 64
  • This question is not about the receiving side of the server (as addressed here) but about the sending side. To cite from the question: *"I basically need to check that the server, __when the other side does not support STARTTLS, drops the email__ rather than downgrading to unencrypted transfer."* Granted, it is far from obvious and I've read it initially the other way too. – Steffen Ullrich Jul 13 '21 at 20:00
  • 1
    @SteffenUllrich It's not clear to me whether the OP is interested in testing an outgoing SMTP relay server, or testing an incoming MX server. But, irrespectively, the same procedure can be used to test an incoming MX server, by making one small change in the first step. Instead of `telnet smtp.gmail.com 587`, you would do `telnet mxserver.example.com 25`. For example, for gmail.com, it would be `telnet gmail-smtp-in.l.google.com 25`. (Gmail does not enforce STARTTLS on its incoming MX servers). – mti2935 Jul 13 '21 at 20:19
  • Reading this again, and reading your comment following the question, I guess there are actually three ways this can be interpreted. Maybe the OP can clarify. – mti2935 Jul 13 '21 at 20:22
  • From my understanding the OP wants to know if the MTA A is using opportunistic or mandatory encryption when delivering a mail to some other MTA (like B). This can not be seen by talking SMTP with A or B, since this only shows if A or B support and enforce STARTTLS to the SMTP client. It can only be seen when trying to deliver a mail from A to B and setting B up in a way that TLS is not supported. If the mail gets delivered (w/o TLS of course) than A does not use mandatory TLS. – Steffen Ullrich Jul 13 '21 at 20:25
  • @SteffenUllrich mti2935 I am sorry I am a complete newb and trying to learn. Sorry I wasn't clear. I am talking about both inbound and outbound emails for users of this email server located at webmail.something.com. This server has 995, 993, 587, 443, 143, 110, 80, 25 ports open. This means it has all SMTP, IMAP and POP services running on it. It lies on webmail.something.com and from that I know its IP. That's all info I have about it, for my black box security test. – user75058 Jul 14 '21 at 08:42
1

NO, you can't test this without sniffing traffic or reviewing logs on the receiving server.

The receiving email system will allow encrypted or unencrypted mail. It's up to the sending email system to require TLS or drop. For google apps (aka gsuite aka google work), this is configurable for specific domains.

There are a couple email flows here.

1. Client -> SMTP server (yourdomain.com)

2. SMPT Server (yourdomain.com) -> SMPT Server (theirdomain.com)

In 1, you're sending email to your email server. You want messages from your machine to other users at yourdomain.com to maintain TLS encryption by default. This is what @mti2935 describes how to test when talking to smtp.gmail.com on port 587.

However, you're asking about 2 - when you send mail to theirdomain.com, your email server will find the remote email server using DNS (MX record), connect to port 25 and fall back to no-TLS.

@mti2935 describes this in the comments when talking about gmail-smtp-in.l.google.com 25.

Legacy

There are no RFCs that require TLS support. Therefore all inbound mail servers support unencrypted communication and all outbound servers support non-tls delivery.

It's up to the sending server to require TLS or drop the communication.

I don't think you can test this without looking at the configuration options on your email server.

Jonathan
  • 2,288
  • 13
  • 16
0

As I understand correctly:

(I do NOT talk about cient (MUA) to (own mailserver) MTA 1)

When MTA 1 (my own mailserver which sends) sends mail to destination MTA 2, it is MTA 2 that decides on what number of port that is listens and if it allows only for TLS or not.

MTA 1 (as my own sending mail server) can perform STARTTLS (not enforced) to ask MTA 2 if it wants to build a TLS connection. But it will be the MT2 that decides on this! It will be MTA 2 that calls the shots on this.

if MTA 1 is not configured for STARTTLS (not enforced TLS), while MTA 2 only allows for a TLS connection, no communication will go trough. End of story!

if MTA 1 is configured with STARTTLS (but not enforced TLS), but MTA 2 does not require it, the communication will not be by TLS, but simply go trough but unencrypted.

Sam Vanderleyden
  • 1