• Halloween is coming! To celebrate the occasion, we dusted off a couple of old skins, and even created a brand new one (Pixel).
    To get into the festive spirit, install the Skins extension.
  • The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • The Plesk Mobile apps for iOS and Android and the Plesk Mobile Center extension have been deprecated, and are no longer available for new installations. In Plesk Obsidian 18.0.84, the Plesk Mobile Center extension will be removed from servers during the upgrade, and the Plesk Mobile apps will lose their server management features.
  • The Social Login extension has been deprecated and will be removed in Plesk Obsidian 18.0.84. After that, it will no longer be possible to log in to Plesk with a Google, Facebook, GitHub account, or with a passkey. Plesk usernames and passwords, as well as logging in with a WebPros Account, are not affected.

Slow (30 sec) response to incoming SMTP connection

R

ranageman

Guest
Incoming SMTP connections are always taking 30 seconds, or just over, to connect. This is causing problems with some senders who have their timeout set to 30 seconds.

While waiting, the following process is running:

root 30626 25648 0 12:14 ? 00:00:00 tcp-env /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true

Here is a debug log from a sender with a simple Perl Net::SMTP connect:

[dan@frame-1 bin]$ time ./smtp_test.pl
Net::SMTP>>> Net::SMTP(2.26)
Net::SMTP>>> Net::Cmd(2.24)
Net::SMTP>>> Exporter(5.566)
Net::SMTP>>> IO::Socket::INET(1.26)
Net::SMTP>>> IO::Socket(1.27)
Net::SMTP>>> IO::Handle(1.21)

<wait 30 secs>

Net::SMTP=GLOB(0x127128)<<< 220 39151.vs.webtropia.com ESMTP
..etc.

Connection is successful.

What might be waiting 30 seconds here?

/ranageman
 
Ha - fixed it myself :)

Put a "-R" as the first item in "server_args" in /etc/xinet.d/smtp_psa, and restarted xinetd.

Apparently smtpd will otherwise wait up to 30s for (useless) remote info from the incoming server, and in my case here, the incoming server timeout was set to about the same....
 
Back
Top