I’ve noticed that when connection to port 25 of one of our servers, it took quite a long time until commands can be sent. To test it, zou connect using telnet>

telnet xxx.xxx.xxx.xxx 25

Where xxx.xxx.xxx.xxx is the IP address of the server on which the mail server is running.

I saw that the connection was immediately established but it took quite some time for the server to send a 220 response. Before this response is received no commands (e.g. HELO, QUIT…) can be processed. Here’s the sequence in which things happen:

1. Client attempts to open an SMTP connection to port 25 of the server.
2. Client waits for the socket connection to be established.
3. Connection established.
4. Client waits for protocol to start (i.e. waits for a 220 message).
5. Server sends a 220 code saying it is ready for action.
6. Now the client can send commands to the server.

The delay occurs in step 4. It takes a long time until the server sends a 220 code.

What happens in the background is that the server validates that the client is trustworthy. This involves performing a reverse lookup of the IP address and checking for known spammers. This can take some time especially if the reverse lookup results in a timeout.

Here are a few things you need to do to get rid of this timeout:

First, make sure that the name servers that are listed in /etc/resolv.conf are working properly.

You can check whether the IP from where the client is accessing the server can be reverse resolved. You can check it with:

# host 192.168.1.1
Host 1.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

If you get a “not found” as shown above then it means the name resolution will not work. You might also get the following:

# host 192.168.1.1
;; connection timed out; no servers could be reached

In this case, the reverse lookup times out. You can prevent the qmail from performing a reverse lookup by changing the xinetd script used to start qmail. The script is located in /etc/xinetd.d. It’s usually called smtp or smtp_psa if you’re using Plesk. It looks like this:

service smtp
{
       socket_type     = stream
       protocol        = tcp
       wait            = no
       disable         = no
       user            = root
       instances       = UNLIMITED
       server          = /var/qmail/bin/tcp-env
       server_args     = /usr/sbin/rblsmtpd  -r sbl-xbl.spamhaus.org /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
}

tcp-env supports the following options:

-r (Default.) Attempt to obtain TCPREMOTEINFO from the
remote host.

-R Do not attempt to obtain TCPREMOTEINFO from the remote
host.

-t
Give up on the TCPREMOTEINFO connection attempt after
timeout seconds. Default: 30.

So we need to use the -R option and could also set the timeout to 0 seconds with the -t0 option:

service smtp
{
       socket_type     = stream
       protocol        = tcp
       wait            = no
       disable         = no
       user            = root
       instances       = UNLIMITED
       server          = /var/qmail/bin/tcp-env
       server_args     = -Rt0 /usr/sbin/rblsmtpd  -r sbl-xbl.spamhaus.org /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
}

Actually -t0 is redundant when using -R. So you can try with -R and with -Rt0 and see whether it makes any difference on your system.

After changing this, you’ll need to restart xinetd:

/etc/init.d/xinetd restart

If you use inet instead of xinetd then you need to update /etc/inetd.conf instead and restart inetd by using:

/etc/init.d/inetd restart

or:

killall -HUP inetd

Please note that Plesk seems to overwrite this file once in a while. So you might loose this setting.

Even after setting this, I’ve seen that from most servers the delay was gone but I still had a remaining 30 seconds delay when connection to the mail server from my laptop.

The mail server uses to auth protocol to contact the client machine. Unfortunately, many firewalls are configured to just ignore these requests without answering. In this case, you’ll also have to wait for a timeout to occur before the mail server goes to the next step.

In order to get rid of it, you can configure a rule using iptables to actively reject connections from the server to a remote port 113 so that you do not have to wait for 30 seconds in case the remote firewall just silently ignores your request. The processing of the request on port 113 is not critical for the functioning of the mail server, it’s safe to prevent it. Execute the following on the server to have these connection rejected by the local firewall on the server:

iptables -A OUTPUT -p TCP --dport 113 -j REJECT --reject-with tcp-reset

Making these few changes made sure that the connection from our other servers was done without delays. And from my laptop I do not get a fix 60 seconds or 30 seconds delay anymore but it’s mostly taking between 1 and 15 seconds.

If after doing all this, it’s still slow, you should check the list of servers used by rblsmtpd. rblsmtpd blocks mail from RBL-listed sites. It uses a list of sources. In my case only sbl-xbl.spamhaus.org. First make sure that all source are still up and running, since this could also cause an additional timeout (the default timeout is 60 seconds). Additionally, checking whether the client is blacklisted also costs time. So you might want to remove rblstmpd and its parameters (basically what’s between -Rt0 and /var/qmail/bin/relaylock above and see whether it’s faster.