On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote: > Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto: >> Il 02/10/2014 18:52, Eric Broch ha scritto: >>> On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote: >>>> Il 02/10/2014 18:02, Eric Broch ha scritto: >>>>> On 10/2/2014 9:10 AM, Eric Broch wrote: >>>>>> On 10/2/2014 8:30 AM, Bharath Chari wrote: >>>>>>> On 10/02/2014 04:59 PM, Eric Broch wrote: >>>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>>> There you go. There's probably nothing you can do from your end - it's >>>>>>> most likely a firewall at their end. However, as a last ditch test, >>>>>>> can you also try to telnet to port 25 on their mail server from >>>>>>> ANOTHER machine on the same network as the QMT machine. >>>>>>> >>>>>>> Wishing you the best :) >>>>>>> >>>>>>> Bharath >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>> Thanks again, Bharath >>>>>> >>>>>> I've done that too (from ANOTHER machine on the same network) with the >>>>>> same results--delay or no connection at all. >>>>>> >>>>>> Eric >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> Hi Bharath, >>>>> >>>>> I just received an email from the problematic mx host's IT department. >>>>> They've done a test with SmtpDiag from their mx host and they cannot >>>>> connect to our mx host from their side either. >>>>> >>>>> Eric >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>> Tonino, >>>> I suppose all your network comes out using the same IP, or more IP >>>> which are mapped to same domain. >>> Yes. On our end we have a NAT(ed) firewall. We also have an MPLS >>> circuit for certain private address ranges on the WAN interface. >>>> >>>> Check if you have reverse IP issues... >>> Reverse DNS checks out Okay on both ends. >>>> >>>> You have the IP address which is connecting to external exchange >>>> server. >>>> That IP should match the IP of the name declared in HELO (o EHLO). >>> There seems to be a Sonicwall email security appliance on their end >>> between our hosts--which, I think, may be the problem--which has a >>> name different than their MX record. >>>> >>>> Check also if name associated with that IP corresponds to HELO name >>>> (some servers are making paranoic controls). >>> The name associated with the IP on their end is different than the >>> response of the HELO command. >> >> This could be a potential problem for them, because some senders >> could refuse to send, but this is another story. >> >> >> >> What makes me think is the fact their answer to your telnet is very >> slow from your network, but fast from other networks. >> >> I'continue checking if it is a DNS issue. >> >> Please double checK: your external IP to name, then again name to IP, >> checking all nameservers. >> >> http://www.dnsstuff.com/tools is very helpful for a complete DNS >> report, and the IP section may go even further, checking all paths of >> all nameservers. > > > Reverse IP resolution uses different servers than name resolution, and > I had problems due to different configurations on reverse IP > nameservers, and that problem was only towards a specific server > which was making a paranoic control. > > Regards, > > Tonino > > > >> >> Regards, >> >> Tonino >> >> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------ >>>> Inter@zioni Interazioni di Antonio Nati >>>> http://www.interazioni.it [email protected] >>>> ------------------------------------------------------------ >>> >> >> >> -- >> ------------------------------------------------------------ >> Inter@zioni Interazioni di Antonio Nati >> http://www.interazioni.it [email protected] >> ------------------------------------------------------------ > > > -- > ------------------------------------------------------------ > Inter@zioni Interazioni di Antonio Nati > http://www.interazioni.it [email protected] > ------------------------------------------------------------
-- Check your DNS by putting an entry in your hosts file. If it connects instantly you've found your problem.
