Postfix connection timeout

Posted on 2007-08-08
Last Modified: 2012-08-13

We're currently running SmarterMail 2.6 on one of our server. Evertyhing works fine excepts for one of our client. Mails from a specific organisation can not be delivered to their mailbox.

This organisation which is sending the e-mail receives the following message:

The e-mail system was unable to deliver the message, but did not report a specific reason.  Check the address and try again.  If it still fails, contact your system administrator.
    < #4.0.0 X-Postfix; connect to[]: read    timeout>

Any idea on what's happening and how to solve it ?
Question by:Raph74
    LVL 30

    Expert Comment

    by:Kerem ERSOY
    It indicates that the mail server receiving e-mail has some problem and once accepting the mail. It just stops responding somewhere and your sendmail waits till the connection timeouts. Then returns this non-delivery notice. This might be from a connection problem or some configuration related issues. It seems that you have nothing to do. It seems that the other end has some problems.

    Author Comment

    Thanks for the reply. What I probably made not clear enough is that our company is the one running the not responding server.

    Our client can receive mails from everyone except from a specific client which receives the error message stated in my initial post. Since this client has no trouble sending mails to otherwise, I believe that there is something not right between the postfix of the company sending the mail and our incoming mail server (SmarterMail).
    LVL 30

    Expert Comment

    by:Kerem ERSOY
    Anyway the answer is the same. This is definitely a network error. You should try to diagnose the connection between two hosts. Check wtih a trace program to see i f there's any hop in between cousing the delay. Or you can just request the sysadmtin to telnet to your 25 port and you can both check logs etc.
    LVL 30

    Expert Comment

    by:Kerem ERSOY
    Anyway the answer is the same. This is definitely a network error. You should try to diagnose the connection between two hosts. Check wtih a trace program to see i f there's any hop in between cousing the delay. Or you can just request the sysadmtin to telnet to your 25 port and you can both check logs etc.

    Author Comment

    First, I want to let you know that network issues is not usually part of my activities but our network admin is unavailable for a few days and our cient is very stressed with this issue that's why I'm trying to find a quick solution. So, let me apologize for any dumb question or remark :)

    I've done a trace (using the basic tracert command and a trace program called AET Tracer Pro) and it gave the same result:

      1    <1 ms    <1 ms    <1 ms
      2     1 ms     2 ms     1 ms
      3     7 ms     2 ms     4 ms
      4    14 ms    11 ms    10 ms []
      5    15 ms    15 ms    22 ms []
      6    91 ms    94 ms    89 ms []
      7    90 ms    99 ms    87 ms []
      8   136 ms   114 ms   117 ms []
      9   138 ms    97 ms   114 ms []
     10   145 ms   132 ms   112 ms []
     11   111 ms   106 ms   110 ms []
     12   144 ms   131 ms   139 ms []
     13   166 ms   162 ms   162 ms []
     14   158 ms   157 ms   163 ms []
     15   169 ms   185 ms   167 ms
     16   174 ms   177 ms   166 ms []
     17   160 ms   160 ms   162 ms []
     18   163 ms   161 ms   162 ms []
     19     *        *        *     Request timed out.
     20     *        *        *     Request timed out.
     21     *        *        *     Request timed out.
     22     *        *        *     Request timed out.
    The postfix server address is [].

    Regarding the sysadmin, since the server seems to be related to Microsoft in some ways (whois), I really don't know who to contact.
    LVL 30

    Expert Comment

    by:Kerem ERSOY
    There's nothing like a "silly question" pls. never bother about thinking in such a way. Yr questions are always welcome. Furthermore I see that you do anything to verify your actions.

    It seems that is the firewall and dropping further traffic. There's nothwing wrong with that. I will suggest you to use a tool like Visualroute. IT gives lots of information.

    My guess is remote server is responding initially but after thet it is getting too much time for ift to respond back. May be taking too much to check user names etc.

    I will suggest you to use a manual SMTP trace. It is like:
    - Get the address of the remote mailer. You can do it with dig or nslookup:
    dig mx
    will return you their pe-mail receiver address
    - telnet to the smtp port:
    telnet 25 (mail exchanger address was returned in the previous step)
    - It will send you an inital greeting such as:
    Connected to (x.y.z.t).
    Escape character is '^]'.
    220 ESMTP sendmail [2.2.10]
    - You respond with:
    ehlo   (replace with your actula domain)
    - It will respond with something like that:
    250-SIZE 10240000
    250 8BITMIME
    - Respond with sender:
    mail from: <your@email.address>
    -it will respond with something like that:
    250 Ok
    - Respond with receiver:
    rcpt to: <receiver@email.address>
    - It will respond with something smilar:
    250 Ok
    - Respond with this:
    - It will respond back with something like that:
    354 End data with <CR><LF>.<CR><LF>
    - Just enter this text:
    Subject: Test Test

    Test test
    (dont for get the "." on its own it is the termination mark.
    - It will respond with something like that:
    250 Ok: queued as 971343B0001
    - Enter this:
    - It will respond with:
    221 Bye
    - Then close the connection:
    Connection closed by foreign host.

    As I told earlier my guess is the remote server has some problems with either verifying your domain (may be DNS errors etc) or verifying the receiver (may be some initial user validation ma y be DAP etc problem). So that it waits indefinitely in one of these steps so that your connection timeouts. Once we can verify that this is a problem with the remote site you can tell it to your customer.


    Author Comment


    In the meantime, I also checked with a colleague the log files of our smartermail server and it seems to drop a lot of packets. Smartermail support seems to say that it is more a sympton than a cause so we are currently trying to redirect the incoming to another server to see if it solves the problem.
    LVL 30

    Accepted Solution


    It might be a DNS problem too. Because when a person tells that he wants to send an e-mail from a domain. th receiving end wants to verify if the domain exists and other checks (if the user is an actual one etc) This might tke time due to DNS problems, Firewall issues etc. Check also the whole path and try to verify opearitons manually with the method I provided above.

    Expert Comment

    Hi there, I'm experiencing a very similar issue myself. The emails that we send to one domain seem to bounceback after a few days with the NDR, above.

    We're using Frontbridge (MS Exchange Hosting) to route email outbound, and that's the "" that's issuing back the "read timeout" error. I imagine that the person sending mail to the OP also uses Frontbridge to route email through?
    LVL 2

    Assisted Solution

    We have seen such Issues , related to blacklists.

    Before receiving email some servers have configured a dnsbl, or blacklists,
    On some ocassions we have seen that people use blacklists that have died or are nolonger maintained, such cases generatea lot of overhead and end up timing out for some servers.

    Services like frontbridge that act as filtering services time out in about 2 minutes of inactivity (which might be because blacklists are not responding).


    Rodrigo O

    Featured Post

    What Should I Do With This Threat Intelligence?

    Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

    Join & Write a Comment

    The biggest nightmare for any Exchange Server Administrator is to keep the server running without any issue. But the problems often come and they need to be resolved efficiently and timely. Here are important troubleshooting points: Define the Pr…
    It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
    Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.
    Sending a Secure fax is easy with eFax Corporate ( First, Just open a new email message.  In the To field, type your recipient's fax number You can even send a secure international fax — just include t…

    729 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    18 Experts available now in Live!

    Get 1:1 Help Now