Retry time not reached for domains

veronicabend

• June 25, 2018 20:55

Hello, This started happenning about five days ago. We have two servers with cPanel & WHM. When one of these servers (server A) sends emails to domains in the shared IP address of the other server (server B), the connection times out and it cannot send. To any domain that is using the shared IP address. The domain resolves, but then it throws this -53 error retry time not reached. If server A sends emails to domains in dedicated IP addresses of server B, that works ok. I installed telnet and tried connecting to port 25 from server A to two different domains using shared IP address of server B. Telnet stayed there trying to connect to that IP until it timed out. I tried connecting with telnet from server A to a domain using a dedicated IP address at server B, and it worked ok as expected. I have emails that server A sent on June 20th to these domains at server B where it cannot send anymore now. We have yet another cpanel server, which can send to the domains at shared IP of server B with no issues at all. I also tried telnet from this server C to server B, and it doesn't time out here, it connects as expected. I have ConfigServer firewall on all servers, has always been there. The server A IP address is whitelisted at server B. I verified this, but I also thought, if this was the case, then server A would not be able to connect to the domains on dedicated IP addresses either. Thanks for any help.

• 

  sktest123

  • June 26, 2018 05:11

  try below.

  • perform a traceroute ip from server A
  • if the traffic reaches, check whether you have any possible dns issues
  • if dns is ok clear the retry lock file and recreate in server B
  • finally if all above fails review thread

  0
• 

  veronicabend

  • June 26, 2018 15:01

  Thank you. Traceroute from server A to server B works ok. Both using traceroute domain.com and traceroute IP. The domain resolves correctly to the IP address. I removed retry and retry lock file at server B, also wait-remote_smtp and its lockfile, and restarted exim. No changes. If I run telnet: telnet xxx.xxx.xxx.xxx 25 where the IP is shared IP address of server B, I get: Trying xxx.xxx.xxx.xxx.... for a long time until it times out. If I run: telnet yyy.yyy.yyy.yyy 25 where this IP is a dedicated IP address also on Server B, it works ok and fast: Trying yyy.yyy.yyy.yyy... Connected to yyy.yyy.yyy.yyy. Escape character is '^]'. So server A can telnet to ONE ip address of server B, but not to the shared IP address. The third server C, can telnet to the shared ip address of server B just fine. I even temporarily disabled the firewall on server B, and tried telnet again, and it kept timing out, no changes. I supposed it was not the firewall since it can telnet the dedicated IP address but tried anyway to be sure.

  0
• 

  veronicabend

  • June 26, 2018 15:30

  Update: I tried telnet from server A to server B, but to port 22. And it works. So telnet from server A to shared IP of server B, port 22, works ok But telnet from server A to shared IP of server B, port 25, times out As exim times out when trying to send email. So the issue is communication from server A to shared IP of server B through port 25. What could have messed this up? Which had been working ok for years until a few days ago?

  0
• 

  cPanelLauren

  • June 27, 2018 17:55

  Hi @veronicabend Have you made any IP address/network related changes in the last week or so? Also, can you provide the output of the following: netstat -plan |grep exim
cat /etc/exim.conf.local
  If you temporarily disable CSF on server B is there any change? Thanks!

  0
• 

  veronicabend

  • June 27, 2018 19:22

  Thanks for replying. I had not made any changes. When I temporarily disabled CSF on server B, nothing changed. Out of the blue, today it is working normally again. I still don't know why it stopped working, or why it is working again. Thanks.

  0
• 

  cPanelLauren

  • June 27, 2018 19:26

  Hi @veronicabend I'm happy to hear it is working again, it almost sounds like there was a networking issue though without more information I can't be sure. If this occurs again please feel free to open a ticket using the link in my signature, at the very least we can take a look and get you pointed in the right direction Thanks!

  0
• 

  NixTree

  • June 28, 2018 02:27

  Most of the cases this in past was a network issues for me or a firewall block / remote servers filters blocking.

  0

Please sign in to leave a comment.