On 10/8/2014 1:26 AM, Tonix - Antonio Nati wrote: > Il 07/10/2014 21:31, Eric Broch ha scritto: >> On 10/4/2014 12:25 AM, Tonix - Antonio Nati wrote: >>> Il 02/10/2014 20:11, Cecil Yother, Jr. ha scritto: >>>> >>>> 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: >>>>>>>>>>>>> qmailtoaster-list-unsubscr...@qmailtoaster.com >>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>> qmailtoaster-list-h...@qmailtoaster.com >>>>>>>>>>>>> >>>>>>>>>>>> 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: >>>>>>>>>>> qmailtoaster-list-unsubscr...@qmailtoaster.com >>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>> qmailtoaster-list-h...@qmailtoaster.com >>>>>>>>>>> >>>>>>>>>> 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: >>>>>>>>>> qmailtoaster-list-unsubscr...@qmailtoaster.com >>>>>>>>>> For additional commands, e-mail: >>>>>>>>>> qmailtoaster-list-h...@qmailtoaster.com >>>>>>>>>> >>>>>>>>> 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: qmailtoaster-list-unsubscr...@qmailtoaster.com >>>>>>>>> For additional commands, e-mail: >>>>>>>>> qmailtoaster-list-h...@qmailtoaster.com >>>>>>>>> >>>>>>>> >>>>>>> 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 to...@interazioni.it >>>>>>>> ------------------------------------------------------------ >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------ >>>>>> Inter@zioni Interazioni di Antonio Nati >>>>>> http://www.interazioni.it to...@interazioni.it >>>>>> ------------------------------------------------------------ >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------ >>>>> Inter@zioni Interazioni di Antonio Nati >>>>> http://www.interazioni.it to...@interazioni.it >>>>> ------------------------------------------------------------ >>>> >>>> -- >>>> Check your DNS by putting an entry in your hosts file. If it >>>> connects instantly you've found your problem. >>> >>> >>> It would be useful it he could put this entry in the remote server >>> :-) . In his server, this does not help in this case. >>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------ >>> Inter@zioni Interazioni di Antonio Nati >>> http://www.interazioni.it to...@interazioni.it >>> ------------------------------------------------------------ >> Thanks all for your help in this. It seems that our respective sites >> have Riverbed Optimization Systems (RiOS) in operation, one set to >> optimize WAN traffic to other RiOSes, the other not. It was this >> conflict between optimizing and not optimizing that was causing the >> problem. > > Which was the practical effect of this misconfiguration? Wrong IP routing? > > Regards, > > Tonino > If I understand your question, there was no issue with routing. Simply, the other site had their RiOS set to opportunistically (with respect to other RiOSes) compress (optimize) internet traffic. In other words, they are sending traffic to us in a compressed state and we are sending traffic to them in an uncompressed state. When our device received their compressed traffic it was dropped, as it was not configured to receive compressed traffic across the internet--it was configured only to receive data in its normal state across the internet.
As it turns out, it is normal practice to NOT compress traffic to other sites with RiOSes unless arrangements are made to do so. Their changing this setting, whether through firmware upgrade or otherwise, is what caused the problem as we WERE sending and receiving email with no problems. > >> >> Eric > > > -- > ------------------------------------------------------------ > Inter@zioni Interazioni di Antonio Nati > http://www.interazioni.it to...@interazioni.it > ------------------------------------------------------------
