Il 08/10/2014 15:04, Eric Broch ha scritto:
> 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-***@qmailtoaster.com
>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>> qmailtoaster-list-***@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-***@qmailtoaster.com
>>>>>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@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-***@qmailtoaster.com
>>>>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@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-***@qmailtoaster.com
>>>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@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
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>>>>> http://www.interazioni.it ***@interazioni.it
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------------------------------------------
>>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>>> http://www.interazioni.it ***@interazioni.it
>>>>>>> ------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------------------------------------------
>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>> http://www.interazioni.it ***@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.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------------------------------------------
>>>> ***@zioni Interazioni di Antonio Nati
>>>> http://www.interazioni.it ***@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.
Ok, thank you a lot. So, finally, the problem was something completely
outside of our suggestions. :-)
Regards,
Tonino
>>
>>>
>>> Eric
>>
>>
>> --
>> ------------------------------------------------------------
>> ***@zioni Interazioni di Antonio Nati
>> http://www.interazioni.it ***@interazioni.it
>> ------------------------------------------------------------
>
--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------