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]
I suppose all your network comes out using the same IP, or more IP which
are mapped to same domain.
Check if you have reverse IP issues...
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).
Check also if name associated with that IP corresponds to HELO name
(some servers are making paranoic controls).
Tonino
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it [email protected]
------------------------------------------------------------
