Mailing List CGatePro@mail.stalker.com Message #104712
From: Urs Grützner <ugruetzner@ems.ch>
Subject: Re: Long delay in SMTP handshake
Date: Tue, 4 Feb 2014 20:38:28 +0100
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
X-Mailer: iPad Mail (11B554a)
Thanks a lot for this elaborate and helpful answer


If I understand correctly:  when I do the Telnet from may laptop, after I was connecting with my mail program, my temporarily IP number is  detected as client, so I do not get a waiting time.


However  the prompt delay was and is set to 0 sec.

 I am still wondering where this 27 sec delay is coming from? It seems to be constantly 27 sec, no random variation. The delay prompt for non-clients seems not to be the culprit. 

Another question: Isn't it possible to see in the log the "knock-knock" of a incoming connection. I only see the answer of our server and the connection closed py peer entry, so I cannot verify the waiting time here (and may be the reason for it) 

Thanks again


Urs







From:"Bill Cole" <cgp-2008@billmail.scconsult.com>
Subject:Re: Long delay in SMTP handshake
Date:Mon, 03 Feb 2014 23:44:11 -0500
To:"CommuniGate Pro Discussions" <CGatePro@mail.stalker.com>
X-Mailer:MailMate (1.7.2r3932)
On 3 Feb 2014, at 11:19, Urs Grützner wrote:

We have Problems with one mail sender SMTP to receive mails on our CGP 5.1.16. On OSX.5.8 The sender goes always into a time out, while trying to make the handshake

The IT responsible always measures 27 secs delay until our server answers with 220 (in between the peer has closed connection, because his time out limit is lower)

Any timeout less than 300 seconds conflicts with the reaffirmations in 2008 (RFC5321http://tools.ietf.org/html/rfc5321#section-4.5.3.2) and 2001 (RFC2821http://tools.ietf.org/html/rfc2821#section-4.5.3.2) of the 1989 (RFC1123http://tools.ietf.org/html/rfc1123#page-62) specification of minimum SMTP timeouts. A piece of software that fails to wait 27 seconds for a 220 reply is not an implementation of SMTP, it is a broken-by-design toy. Anyone trying to use such a thing for sending mail on the open net is like a child trying to drive a toy car on an open highway.

When I make myself a Telnet connection from different sites, I get the 220 always immediate.

1. I do not understand these contradictory results

The most common cause of a delay on that scale that is not common to all non-client sources is broken reverse DNS for the source IP address that results in DNS timeouts (rather than faster explicit DNS failures.)

However, that does not seem to be the cause in your case...

2. If this delay as the sender measures is reality: is a wrong setup in our server responsible for that? Which one?

As Thomas Bleek has noted, you can set an intentional prompt delay in CGP that applies only to non-client IP addresses. That delay is a very useful low-cost way to catch "spambot" senders, but anything more than 5 seconds adds little to the bot identification rate while delaying nearly all mail.

There's nothing formally wrong with setting a long delay, but there are an amazing number of children in toy cars trying to navigate the Internet and you may want to accommodate some of them. It also can be annoying to have every message delayed and even more annoying to accommodate the large number of waiting SMTP connections you can pile up by imposing a long delay.

Thanks for help


[ursg@Urs-MacBook-Air-Mountain-Lion|~]%  time telnet mail.ems.ch 25                      12:14 ttys000 |
Trying 194.209.14.153...
Connected to mail.ems.ch.
Escape character is '^]'.
220 ems.ch ESMTP CommuniGate Pro 5.1.16 is glad to see you!

That specific reply from CGP indicates that you connected from a client IP. That could include an IP that you've recently authenticated to CGP from.

I didn't do this from your laptop :) --

  $ time telnet mail.ems.ch 25
  Trying 194.209.14.153...
  Connected to mail.ems.ch.
  Escape character is '^]'.
  quit
  477 you did not wait for a prompt
  Connection closed by foreign host.

  real 0m27.548s
  user 0m0.016s
  sys 0m0.006s

The 477 reply is a sure sign that your server is intentionally delaying the initial prompt and turning away clients that talk too fast.

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster