I have a very small scale personal mail server than I run on a VPS. Yesterday I migrated this, and changed the DNS records with the registrar (godaddy). Because of some limitations on the new host OS, I had to build the mail server software (courier) from source; it's something that's run without problems for several years and I haven't paid much attention to, so getting it all set up and configured took much more time and created much more stress than I intended. That provided me with a host of red herrings with regard to a problem on the SMTP port (25) -- this morning it was okay and received mail, but when I went to check it on sites like "MX tools" the response was very slow until this afternoon, when some of them started just plain timing out.1

This led me to start checking it myself, first using openssl s_client to make sure STARTTLS was working, but that timed out. Plain old telnet timed out. The other ports courier was responsible for (imap-ssl, pop-ssl, and even smtp-ssl on 465) were fine -- CONNECT happened instantly.

Since then I've completely disabled the mail server. I.e., no courier software is running, period. I then started a very simple web server on port 25 and 26 to see what difference there is, and used traceroute -T -p [N] cognitivedissonance.ca from here to check the connection.

The report for port 26, and any other port on the server, went fine. 10 or 11 hops from Toronto to San Franscisco in < 100 ms.

However, port 25 stops right after my router (192.x) -- I get 30 * * * and never reach the destination. So I tried -w 300 -m 100, i.e.:

  • Timeout each hop at 5 minutes.
  • Give up after 100 hops.

Traceroute is still running after timing out on trying more than 20 * * *.

With regard to my own firewalls:

  • Any TCP connection to the server is allowed from here.
  • Currently the server's iptables (and ip6tables) are set completely open, i.e., just accept everything.

So this is not a firewall issue on the client or the server.

It is also not a dead port on the server, which I can connect to without issue via SSH. lsof -i TCP:25 on the server shows a LISTEN. Further, telnet localhost 25 or anything else on the server works instantaneously.


Has something propagated around such that my SMTP port has been blacklisted so badly in such a short time I cannot use it for any purpose? Or else it is just that first critical hop through my ISP? (I am going to re-enable the mail server and leave it on to see if it picks up mail, since I can still reach the remote system and use it on any other port.)

Is this last conjecture the most likely? If so, why would my major telecom ISP suddenly do this? Are there other possibilities? What can I do about this?

Note I've never used the domain for spam and no one is relaying through it either. As mentioned, this is a very small scale, harmless, personal mail server I've been using for years from a different VPS location (the provider of which is the same).

1. I had been assuming these sites did their analysis server-side, so if they couldn't reach 25, it was a universal issue and not just at my house -- I now think they in fact do it from your browser which is why they reported the same problem I found (see comments on the accepted answer).

closed as off-topic by Iain, Jim B, mdpc, Jenny D, Flup May 27 '16 at 10:19

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

  • "Questions on Server Fault must be about managing information technology systems in a business environment. Home and end-user computing questions may be asked on Super User, and questions about development, testing and development tools may be asked on Stack Overflow." – mdpc, Jenny D, Flup
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Did you contact your ISP? It may be their policy to block 25 as a preventative measure, and need to request that it be opened – pete May 10 '16 at 23:23
  • @pete Not yet. See my comment on neofug's answer. If it isn't clear from the question, I've been doing exactly the same thing already for several years, all I did was change the location of the server. I did not change the MTA configuration, the domain, the (valid) SSL cert, etc., and the TTL on my DNS record is 60 minutes. – goldilocks May 10 '16 at 23:55
  • You may be right though, I've just tried from another server and it goes through right away :/ Dunno why all those "MX tool" services had such a problem unless they actual work via your browser. – goldilocks May 11 '16 at 0:00

Many ISPs block port 25 outbound and instead require an authenticated connection be established on an alternate port (465, 587, in most cases). This is to prevent a compromised computer connected to their network from spewing spam from the ISP's mail servers, whose reputation being lowered or the server being blacklisted likely effects a large number of other users. The easiest way to move forward (without switching to a different ISP) would be to configure your email server to use authentication for outgoing mail.

  • I don't doubt this, but it seems an incredible coincidence that they suddenly instituted a policy on exactly the same day I migrated the server. As per the question, I didn't really change anything (I migrated for reasons unrelated to mailing, I've been using the "new" slice for a few months). I.e., I've already been doing exactly this for more than 2 years. It could be some kind of mechanism that's been triggered by the ISP.. But: that doesn't explain why testing services such as "MX tools", who are external to my ISP, also time out. Try telneting my 25 -- the domain in is the Q. – goldilocks May 10 '16 at 23:52
  • I just tried telneting from my other server (the one migrated from), and I think you may be right. I'd presumed free websites like "MX tools" tested from their own servers, I'm now thinking they actually use your browser to run the test. I'm beat for today but I'll give you the tick when I'm sure about this tomorrow. Thx. – goldilocks May 11 '16 at 0:03
  • @goldilocks I can reach your server on port 25 just fine. There's no problem on that end. But of course, your personal email client should be sending to port 587, not port 25. – Michael Hampton May 11 '16 at 3:37
  • @MichaelHampton Yeah. I did not think a separate mail submission port was necessary if I was using STARTTLS to keep the submission secure anyway; before I was using 495, not 587. So, when I said in the question, etc., that "the server is configured the same, I've been doing it this way for two years", that's true, but I did reconfigure the clients (mostly to use IMAP instead of POP) at the same time. When I did that, I set the submission port to 25. So it is back on 495 now and works. :) – goldilocks May 11 '16 at 12:57
  • @goldilocks Do yourself a favor: Stop using non-standard ports, right now. This problem was caused by you using the wrong port to begin with, and you're still using the wrong port, so you're going to have some other problem in future, one that nobody can foresee yet. – Michael Hampton May 11 '16 at 14:02

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