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
Eric
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it to...@interazioni.it
------------------------------------------------------------
