Raph74
asked on
Postfix connection timeout
Hi,
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.
< outbound6-cpk-R.bigfish.co
Any idea on what's happening and how to solve it ?
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.
< outbound6-cpk-R.bigfish.co
Any idea on what's happening and how to solve it ?
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.
ASKER
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).
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).
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.
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.
ASKER
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 xxx.xxx.xxx.xxx
2 1 ms 2 ms 1 ms xxx.xxx.xxx.xxx
3 7 ms 2 ms 4 ms xxx.xxx.xxx.xxx
4 14 ms 11 ms 10 ms viking816-from-ewapps-1765
5 15 ms 15 ms 22 ms fa6-0-6-cr2.BRU.router.col
6 91 ms 94 ms 89 ms pos7-0-cr1.NYC.router.colt
7 90 ms 99 ms 87 ms ge-6-2.car2.NewYork1.Level
8 136 ms 114 ms 117 ms vlan99.csw4.NewYork1.Level
9 138 ms 97 ms 114 ms ae-92-92.ebr2.NewYork1.Lev
10 145 ms 132 ms 112 ms ae-2.ebr1.Chicago1.Level3.
11 111 ms 106 ms 110 ms ae-68.ebr3.Chicago1.Level3
12 144 ms 131 ms 139 ms ae-3.ebr2.Denver1.Level3.n
13 166 ms 162 ms 162 ms ae-2.ebr2.Seattle1.Level3.
14 158 ms 157 ms 163 ms ge-2-0-0-52.gar1.Seattle1.
15 169 ms 185 ms 167 ms 65.59.235.6
16 174 ms 177 ms 166 ms ge-5-2-0-54.tuk-64cb-1a.nt
17 160 ms 160 ms 162 ms ten9-1.cpk-76c-1a.ntwk.msn
18 163 ms 161 ms 162 ms gig1-3.cpk-76e-1.ntwk.msn.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
The postfix server address is outbound6-cpk-R.bigfish.co
Regarding the sysadmin, since the server seems to be related to Microsoft in some ways (whois), I really don't know who to contact.
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 xxx.xxx.xxx.xxx
2 1 ms 2 ms 1 ms xxx.xxx.xxx.xxx
3 7 ms 2 ms 4 ms xxx.xxx.xxx.xxx
4 14 ms 11 ms 10 ms viking816-from-ewapps-1765
5 15 ms 15 ms 22 ms fa6-0-6-cr2.BRU.router.col
6 91 ms 94 ms 89 ms pos7-0-cr1.NYC.router.colt
7 90 ms 99 ms 87 ms ge-6-2.car2.NewYork1.Level
8 136 ms 114 ms 117 ms vlan99.csw4.NewYork1.Level
9 138 ms 97 ms 114 ms ae-92-92.ebr2.NewYork1.Lev
10 145 ms 132 ms 112 ms ae-2.ebr1.Chicago1.Level3.
11 111 ms 106 ms 110 ms ae-68.ebr3.Chicago1.Level3
12 144 ms 131 ms 139 ms ae-3.ebr2.Denver1.Level3.n
13 166 ms 162 ms 162 ms ae-2.ebr2.Seattle1.Level3.
14 158 ms 157 ms 163 ms ge-2-0-0-52.gar1.Seattle1.
15 169 ms 185 ms 167 ms 65.59.235.6
16 174 ms 177 ms 166 ms ge-5-2-0-54.tuk-64cb-1a.nt
17 160 ms 160 ms 162 ms ten9-1.cpk-76c-1a.ntwk.msn
18 163 ms 161 ms 162 ms gig1-3.cpk-76e-1.ntwk.msn.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
The postfix server address is outbound6-cpk-R.bigfish.co
Regarding the sysadmin, since the server seems to be related to Microsoft in some ways (whois), I really don't know who to contact.
Hi,
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 207.46.36.82 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 domain.com mx
will return you their pe-mail receiver address
- telnet to the smtp port:
telnet mail.exchanger.com 25 (mail exchanger address was returned in the previous step)
- It will send you an inital greeting such as:
Connected to localhost.sibernet.com.tr (x.y.z.t).
Escape character is '^]'.
220 mail.exchanger.com ESMTP sendmail [2.2.10]
- You respond with:
ehlo your.domain.com (replace your.domain.com with your actula domain)
- It will respond with something like that:
250-diderot.sibernet.com.t
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH CRAM-MD5 PLAIN DIGEST-MD5 LOGIN
250-AUTH=CRAM-MD5 PLAIN DIGEST-MD5 LOGIN
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:
data
- 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:
quit
- 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.
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 207.46.36.82 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 domain.com mx
will return you their pe-mail receiver address
- telnet to the smtp port:
telnet mail.exchanger.com 25 (mail exchanger address was returned in the previous step)
- It will send you an inital greeting such as:
Connected to localhost.sibernet.com.tr (x.y.z.t).
Escape character is '^]'.
220 mail.exchanger.com ESMTP sendmail [2.2.10]
- You respond with:
ehlo your.domain.com (replace your.domain.com with your actula domain)
- It will respond with something like that:
250-diderot.sibernet.com.t
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH CRAM-MD5 PLAIN DIGEST-MD5 LOGIN
250-AUTH=CRAM-MD5 PLAIN DIGEST-MD5 LOGIN
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:
data
- 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:
quit
- 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.
ASKER
Thanks.
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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 "bigfish.com" 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?
We're using Frontbridge (MS Exchange Hosting) to route email outbound, and that's the "bigfish.com" 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?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.