Mail gateway allowing telnet connections

Question

Our organization is currently being tested by a IT security firm who have stated that while our internet facing mail gateway is not an open relay, they can connect to it on port 25 using telnet and check if an internal address is valid or not using RCPT TO.

The firm has stated that this leaves us open to address enumeration, phishing of our staff, and an exposed service with no authentication requirement that may lead to compromise.

As an organization we have to accept email from any legitimate public email address but we of course have protections in place for spam etc.

I have been told that unauthenticated telnet or similar types of connections to port 25 of our external gateway should be blocked but I don't see a way of this being possible or am I incorrect in saying so.

I'm facing the same quandary regarding being told that we should prevent our email addresses from being verified in this or any other way to prevent enumeration. I don't see a way to do this given the nature of our organizations business and the need to ensure members of the public know that they have contacted a legitimate address in our organization.

Any advice is greatly appreciated.

Answer 1

I have been told that unauthenticated telnet or similar types of connections to port 25 of our external gateway should be blocked but I don't see a way of this being possible or am I incorrect in saying so.

You are right, you can't really run your own mail exchange server and also block port 25 on that server.

For example, Google's mail exchangers accept arbitrary telnet connections on port 25, and they allow username enumeration by RCPT TO, and they are doing just fine.

For example, Google's mail exchange server at 142.250.141.25 allows connections on port 25 and responds with "550-5.1.1 The email account that you tried to reach does not exist." if the account doesn't exist. And responds with "250 2.1.5 OK" if the account does exist. However, they reject any message that doesn't conform to RFC 5322, and probably do a lot of other anti-spam stuff.

Any advice is greatly appreciated.

Maybe don't hire this same IT Security Firm again. Or ask them to explain in detail exactly what they mean and exactly what reasonable mitigations could protect against this "vulnerability." But, I think they are probably just giving you a false positive without thinking about it.

Answer 2

they can connect to it on port 25

If you need to accept mail from outside senders, then you need to have port 25 open to the public and listening for incoming TCP connections. Telnet (and many other tools) can initiate a TCP connection with a server.

check if an internal address is valid or not using RECT TO

This is also typical.

In fact, you can run a simple test, and see Google's public-facing MX's for its Gmail service exhibit both of the above behaviors:

$ telnet aspmx.l.google.com 25
Trying 2607:f8b0:400d:c02::1b...
Connected to aspmx.l.google.com.
Escape character is '^]'.
s: 220 mx.google.com ESMTP f4-20020ac840c4000000b002de6af24051si1132472qtm.638 - gsmtp
c: ehlo test
s: 250-mx.google.com at your service, [2603:301d:1300:7700:5d81:163:e3ea:b0d2]
s: 250-SIZE 157286400
s: 250-8BITMIME
s: 250-STARTTLS
s: 250-ENHANCEDSTATUSCODES
s: 250-PIPELINING
s: 250-CHUNKING
s: 250 SMTPUTF8
c: MAIL FROM: <test@test.net>
s: 250 2.1.0 OK f4-20020ac840c4000000b002de6af24051si1132472qtm.638 - gsmtp
c: RCPT TO: <someaddressthatdoesnotexist@gmail.com>
s: 550-5.1.1 The email account that you tried to reach does not exist. Please try
s: 550-5.1.1 double-checking the recipient's email address for typos or
s: 550-5.1.1 unnecessary spaces. Learn more at
s: 550 5.1.1  https://support.google.com/mail/?p=NoSuchUser f4-20020ac840c4000000b002de6af24051si1132472qtm.638 - gsmtp