Is there a terminal command to determine if ISP blocks port 25 without actually setting up email server?

Question

I am contemplating setting up an email server, but concerned that the ISP will block port 25. It would be nice to know that port 25 is / is not open before going through the effort to setup the email server.

Is there a terminal command to determine if my ISP blocks port 25 without actually setting up email server?

Answer 1

There are two separate things you need to test: whether they block outgoing connections on port 25 (which corresponds to your server sending messages), and whether they block incoming connections on port 25 (your server receiving messages).

Testing outgoing connections is fairly easy. Pick a known-good mail server to use as a test target. Here I look up the mail server for @google.com:

$ host -t mx google.com
google.com mail is handled by 10 smtp.google.com.

Then I use nc to try to open a connection to it and see if I get a successful connection and an SMTP server message:

$ { sleep 2; echo "quit"; } | nc -w5 smtp.google.com. 25 && echo "connection succeeded" || echo "connection failed"
220 mx.google.com ESMTP p5-20020a170902eac500b001d7077d91b1si1426011pld.170 - gsmtp
221 2.0.0 closing connection p5-20020a170902eac500b001d7077d91b1si1426011pld.170 - gsmtp
connection succeeded
$ 

The "220 ..." message is part of the SMTP protocol, which is basically the server saying "welcome...". That and the "connection succeeded" tell me that the connection worked.

The command I used is a bit complex, so here's what all that does: the nc command tries to open a connection to port 25 on the server (with -w5 making it time out after 5 seconds if there's no response). It waits two seconds, then sends the "quit" SMTP command to politely tell the server it's just going to close the connection without sending any actual email. The two-second delay is there because some servers will block you as a spammer if you start sending commands before it sends that "220 ..." welcome message. Finally, the echo commands at the end are there because nc itself doesn't print anything to indicate whether the connection succeeded or failed, so those give an appropriate message based on the exit status of nc.

If the connection had been blocked, it would've just exited (maybe after a few seconds) and printed "connection failed", without any of the "220 ..." stuff from the server.

There are some other, more obscure possibilities. As gidds pointed out in a comment, if you get "220 ..." and "connection succeeded" message BUT the "220 ..." message says the server belongs to your ISP rather than the company you were trying to test with, then your ISP is probably intercepting outgoing connections (rather than blocking them outright), and you'll have to investigate their policies to find out the implications. This can be a bit ambiguous, since the server name doesn't always match what you'd expect (e.g., the server I called "smtp.google.com" answers as "mx.google.com"), so testing with multiple different target servers may help -- if they all answer the same way, that's a really good indication you're being intercepted.

It's also possible to get conflicting indications, like a "220 ..." message followed by "connection failed", or nothing from the server but a "connection succeeded" from the status check. If these happen, you'll need to do some more detailed checking (like maybe running tcpdump to watch the connection) to figure out what's going on.

Testing incoming connections is more complicated, because you first have to do all the work of setting up port forwarding for port 25 (assuming you're on NAT), finding your public IP address, etc. Basically, you have to configure your part of your network connection to receive incoming connections on port 25.

But you don't actually need to set up a mail server, just something that'll listen on port 25. So once you've got your network set up, just run sudo nc -l 25 on the computer you want to use as a mail server (and you'll need to authenticate with your password for sudo).  This'll listen for connections on port 25 (and print any content it receives); it should just sit there waiting for something to connect to it.

Then you need to test access to it from outside your private network (and preferably from outside your ISP's network). The simplest test is probably to go to https://www.yougetsignal.com/tools/open-ports/, make sure it has your public IP correct, set the port number to 25, and click "Check". If it worked, it should say "Port 25 is open on [your IP here]" and the sudo nc command will exit (since it's gotten the connection it was waiting for) without printing anything (since the test didn't send any actual data).

If the connection didn't go through, the yougetsignal page will say something like "Port 25 is closed on [your IP here]", and sudo nc will still be waiting for a connection (you can use Ctrl+C to kill it).  This means that either the ISP is blocking access, or something in the setup you did is incorrect.

Answer 2

The simplest thing I can think of is to use tcpdump and sniff the packets coming in to your public interface:

# tcpdump -i public tcp port 25

Then log in to a system on a different ISP's network and:

$ telnet myhost.example.com 25

and see whether tcpdump displays any incoming packets.

Answer 3

You can run (as root to be able to bind to a port < 1024):

socat -u tcp-listen:25,reuseaddr 'system:
  echo "Got a connection from ${SOCAT_PEERADDR}:${SOCAT_PEERPORT}"'

Then when trying to send an email to anyone@[a.b.c.d] from some email provider, with a.b.c.d being the public IP address by which your server can be reached as, should cause it to output something like:

Got connection from 1.2.3.4:59604

Confirming the port is not blocked.

Answer 4

One option would be to set up a very basic web server listening on port 25 and then use any of the web services available to see if you can reach your system. Not a recommendation but I used https://www.montastic.com/ and scanned http://mail.example.com:25 to see if the port is internet-available.

Answer 5

Non-answer: Just don't do it. For incoming e-mail, it's possible but kind of tricky to set up an MX record for a dynamic IP address. But for outgoing e-mail, forget about doing that on a residential/dynamic IP address. Even if your ISP doesn't block the port 25, most sane mail servers should refuse to accept mail from your IP address.

Renting a small virtual private server with static IP address isn't expensive, and you get a reasonable chance of transmitting mail successfully. With some services such as Gmail you might still be out of luck as those tend to use anti-spam mechanisms which favor bigger operations and don't have effective mitigation pathways when they block your mail.

Answer 6

Do a telnet email test to your mail server's, also ISP's block port 25 on non-business accounts usually, so it is probably blocked unless you pay for a business class package

https://learn.microsoft.com/en-us/exchange/mail-flow/test-smtp-telnet?view=exchserver-2019