Users have been reporting emails not coming through. There is a certain domain that is trying to email us and they get these failure notices;

"This is a delivery failure notification message indicating that an email you addressed to email address : -- XXXXX.XXXXXX@XXX.XX could not be delivered. The problem appears to be : -- Communications error Additional information follows : -- Null result from socket This condition occurred after 30 attempt(s) to deliver over a period of 92 hour(s). If you sent the email to multiple recipients, you will receive one of these messages for each one which failed delivery, otherwise they have been sent."

I need help troubleshooting, I haven't seen this error before and google is not showing results for this specific error.

  • Could you check the server logs and add them ? – Dom Jun 28 '17 at 7:57
  • The error message looks like a timeout. However without knowing more (if a server on your side or on there side generated this error message) it would be hard to give you some advises. – BastianW Jun 28 '17 at 8:38
  • Will try and get server logs shortly, if it helps I can't even see these emails hit our exchange server. – RobAtkins Jun 28 '17 at 8:58
  • Just spoken to the senders IT dept, they say the emails are sitting in their outgoing queue. The spoke with Mimecast and they have been told it is an issue with our domain by the looks of it as it's only mail going to us. The only thing is I asked for the bounce back email header and he says he isn't able to get to it. – RobAtkins Jun 28 '17 at 10:51
  • Been looking further into this and another external client that isn't using Mimecast is also having issues sending in they got a 4.4.7 Message delayed bounceback. Mimecast have said that it looks like it is an issue with the SMTP connection between our external domain and exchange server. After our firewall rebooted one clients emails did come through but the rest didn't and are still stuck in their outgoing queue. One client did say they had another bounceback come in saying that their email was rejected due to size limit so it does look like that one did hit the mail server. – RobAtkins Jun 29 '17 at 7:49

I am not sure whether this will help, but we have just had experience of something with very similar symptoms.

It came down to the recipient's firewall rejecting the communication as the SMTP header was 'too long'. The recipient has updated the software on their firewall and the emails are now flowing.

  • We have narrowed it down to be something to do with their external footer program Exchange, all the people that are having issues sending in are using it. Turns out their Auto Replies have been coming through and they have no footer on them but anything else just doesn't hit our exchange server. – RobAtkins Jul 5 '17 at 10:40
  • Thanks default value on Firewall was set to a 20k limit on the header. Turns out Microsoft have been having issues with not stripping diagnostic parts of the header out before sending when using 365, meaning the header values had reached about 36k. Thanks again – RobAtkins Jul 6 '17 at 10:01

The error message itself is somewhat clear: communication between two mail transfer agents (MTA) has been failed. The key to this problem is not the exact error message, but which server generated it. You could detect this by the last (top) Received: header of the attached headers of the bounced message & the first (bottom) Received: header of the bounce itself.

If we have the simplest situation; MUA -> sender MTA -> your MTA -> mailbox; this kind of error may occur most likely on the sender MTA, when it tries to connect your MTA. Therefore, while suggested in the comments, this wouldn't even appear in the logs on your mail server. At the most there could be two events from connect & disconnect. Also, if mail from anywhere else is arriving normally, it's unlikely that this one sender domain would be treated differently.

When you can limit the problem to a single server:

  • Someone should examine the logs on the originating server; the one that sent the bounce message. If the server is on the sender side, you don't even have access to these logs, and you couldn't do any testing either; pass the instructions.
  • Test that the sender MTA gets correct MX records for the recipient domain.
  • Test that connection to this mx.example.com:25 can be established, for example that you get the correct SMTP greet message when trying to telnet your MTA :25 from the sender MTA.
  • Check routing between the servers, e.g. with traceroute mx.example.com.

If the problem is somewhere else, all the same applies to that server and the next MTA.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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