On 10/2/2014 1:32 AM, Bharath Chari wrote: > On 09/25/2014 06:44 PM, Bharath Chari wrote: >> On 09/25/2014 05:50 PM, Eric Broch wrote: >>> Hmmmm. Is it always exactly one minute from begin to end? That would >>>> appear to indicate some timer cutting out. It could be spamdyke >>>> closing the session depending on your idle-timeout-secs= value. I'm >>>> guessing 60, which is probably ok. I've upped mine to 180, and I don't >>>> recall exactly why I did that. Wouldn't hurt to bump it up I suppose. >>>> >>>> Still, the other end should have replied to your 220 message before 58 >>>> seconds elapsed. >>>> >>>> I wonder if there's a routing table misconfigured somewhere along the >>>> way. I've seen instances where an errant routing table entry can cause >>>> every nth packet to get dropped along the way. Are you seeing reliable >>>> pings over a period of a minute or so? If not, I'd suspect a network >>>> issue. >>>> >>>> At this point, I'd guess that QMT may be terminating a little soon, >>>> and there's also a network problem somewhere along the way. >>>> >>>> Again, just a guess. >>>> >>>> P.S. Nice to see such accomplished people as Tonino and Bharath >>>> helping out. Thanks guys! >>>> >>> No, it is not always one minute, sometimes it is up to thirty seconds >>> longer. I don't think spamdyke is closing the session as my >>> idle-timeout-secs is set to 480, and I don't recall either why I set >>> mine so high. While telnet(ing) to their host on port 25 initially and >>> it is 'trying' to connect, I can open another terminal and run the same >>> telnet command and I'll get their greeting right away. >>> >>> I agree, their host should have replied faster than 58 seconds after >>> the >>> SMTP greeting, unless the greeting is never getting to there host. >>> There >>> host does not have ICMP protocol turned on. I could ask them to do so. >>> >>> If I have spamdyke set to terminate after 480 seconds what else >>> would be >>> terminating the connection? >>> >>> And, ditto. Thanks for the help Tonino and Bharath!!! >>> >> Thanks hardly required. The problem still remains :( >> OK, since you're having a problem even when doing a RAW telnet (the >> initial connection), the MTA related issue can be ruled out for now. >> However, it would be great if you could telnet from ANOTHER network >> and see if the pattern remains the same (of the initial connection >> being slow, and the next connection being fast). >> >> Are you doing the telnet using IP or hostname? Let's rule out DNS >> lookup related issues. >> >> Bharath > > @Eric Broch: Curious to know how this issue panned out. Did it resolve > itself? > > Bharath > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Bharath,
And, also, it doesn't matter whether I use the hostname of the IP Address same results. I can telnet on port 25 to the problem host from [an]other location(s) and it works just fine. Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
