Postfix timed out while receiving the initial server greeting

I obtain the warning in the title when I use IPConfig 3 as outgoing mail server, but only for certain destination domains.

After some testing, I've noticed that this happens only with destination mail servers that does not respond immediately to a connection to their TCP:25 port. In these cases my Postfix think that the destination server is not responding, write the warning "timed out ..." to the mail.err log and maintain the undelivered messages in the queue (postqueue -p), indefinitely...

I would have found a solution, consisting in configuring a custom "transport" in Postfix and adding the parameters "smtp_connect_timeout" and "smtp_helo_timeout" to this new transport (in /etc/postfix/master.cf) but I'm wondering which is it the best way to realize this in ISPConfig3.
Within ISPConfig3 there is no "/etc/postfix/transport" file (replaced by the "mail_transport" table in the "dbispconfig" database, I suppose) and then I'm wondering if it is correct to manually modify "main.cf" (adding the file to "transport_maps"), "transport" and "master.cf" files.

Hi Luca, sorry to grave-dig your thread here, but I've been experiencing the same issue and your suggested fix did, in fact, solve the problem. However, considering the implications of disabling tcp_window_scaling (effectively setting your maximum TCP window size to 64k), this does not seem like the best practical long-term solution - especially if the server is performing other duties such as web-serving.

Since posting this, have you discovered any other way around the issue? Or, can anyone else chime in on perhaps a better way to handle such troublesome remote mail servers?

RFC 2821 (SMTP) says that a client should wait 5 minutes for the "Initial 220 Message". Many SMTP servers accept a TCP connection but delay delivery of the 220 message for different reasons (slamming/GreetPause , more mail to be processed, ..others..)

Insert in your postfix main.cf a higher timeout value (default is 30 sec).. i think 120 sec should be enough:

Hi Lancia,
no, I didn't find other solutions... In my case setting the tcp_window_scaling parameter did not have collateral effects, apparently...
In any case if you find alternative solutions, let me know (thank you).
Ah, I do not remember for sure if I tried the smtp_connect_timeout, but I think of having given it a try, with no great results...
Good luck,
Luca

Hi Luca, sorry to grave-dig your thread here, but I've been experiencing the same issue and your suggested fix did, in fact, solve the problem. However, considering the implications of disabling tcp_window_scaling (effectively setting your maximum TCP window size to 64k), this does not seem like the best practical long-term solution - especially if the server is performing other duties such as web-serving.

Since posting this, have you discovered any other way around the issue? Or, can anyone else chime in on perhaps a better way to handle such troublesome remote mail servers?

I try to echo 0 > /proc/sys/net/ipv4/tcp_window_scaling but I'm not allowed. The files permissions are 444, i try to change to 644 but it won't allow me to change it. I am running Debian 6 on a VPS Virtuozzo