# qmail smtpd really really slow

## mtombs

Hi

I've been using qmail for a year, no problems. But this weekend, for some reason, smtpd has become so slow that clients time out. If I do

telnet localhost 25

It takes about 90 secs before I get a response. The server is not busy; its not hitting any limits. 

Any suggestions?

thanks

Mark

----------

## adaptr

Erm.. log files ?

Compare timestamps from different transactions, time taken within a single transaction - you should be able to see where the time goes.

----------

## mtombs

Heres a section of the qmail-smtpd log file. Its not very informative:

```

@40000000407bcbff1c9ec64c tcpserver: pid 27382 from 195.42.198.23

@40000000407bcbff1ca12f7c tcpserver: ok 27382 0:192.168.2.3:25 :195.42.198.23::8759

@40000000407bcc221e329934 tcpserver: status: 2/40

@40000000407bcc221e39155c tcpserver: pid 27384 from 127.0.0.1

@40000000407bcc221e3b577c tcpserver: ok 27384 0:127.0.0.1:25 :127.0.0.1::3112

@40000000407bcc3a212c5cec tcpserver: end 27382 status 256

```

If I try and connect to the smtp server via telnet, this is what happens:

I type : 

```
telnet localhost 25
```

Immediate response:

```

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

```

Then it waits for 90 seconds, no activity anywhere...

then:

```
220 mail.niku.se ESMTP
```

Now that should not be.

thanks

Mark

----------

## skunkworx

Did your DNS information change recently, or have you been having DNS trouble lately?

The #1 cause of qmail SMTP connections suddenly taking a long time to respond is bad DNS.  Usually, tcpserver (qmail's network listening daemon) will do a look-up on the connecting server's IP address, so that it can record the server's name in its logs.  If there is a problem with the look-up, it will hang until it times out, causing a delay just like like the one you are seeing.  The fact that your logs only show IP addresses and not server names supports this.

If you're using version 1.03-r13 or newer of the qmail ebuild, try adding "-H" to the TCPSERVER_OPTS definition in either /var/qmail/control/conf-common or /var/qmail/control/conf-smtpd.  Then, restart qmail.  If DNS is the problem, then the delay should go away at this point.  Alternatively, if you have control over DNS for your network, make sure the name server is running properly, and that the IP addresses you are trying to connect from have correct name information.

"-H" tells tcpserver not to try and look up any connecting servers' host names.  See the tcpserver documentation for more information.

----------

## mtombs

The problem went away when I updated qmail to 1.0.3-r13. I tried testing my DNS settings, and all was OK. I had the flag to stop lookups in my script already. According to the people on the qmail mailing list, my problem was actually something to do with rbl, but don't ask me what. 

By the way, they don't think very highly of the gentoo qmail packages over there   :Wink: 

----------

## skunkworx

 *mtombs wrote:*   

> The problem went away when I updated qmail to 1.0.3-r13. I tried testing my DNS settings, and all was OK. I had the flag to stop lookups in my script already. According to the people on the qmail mailing list, my problem was actually something to do with rbl, but don't ask me what.

 

That's plausible.  I don't use any black-listing tools, so I didn't think of that.  Anything that requires the gathering of information across the network has the potential to slow things down if the service or connection goes flaky.  Usually it's DNS in cases like this, but not always.

 *mtombs wrote:*   

> By the way, they don't think very highly of the gentoo qmail packages over there  

 

They aren't entirely without reason.  The qmail ebuild is quite a behemoth, chock full of patches and configurations that not every qmail expert recommends.  It's not just Gentoo they are critical of, however.  Really they are critical of anything that would automate the qmail installation process, particularly for people who have never used qmail before.  It's a small part of the big debate of automation and user-friendliness vs. complete control and forcing people to be aware of exactly what is happening on the machines they are responsible for.  Fortunately for us, Gentoo has done a pretty good job of striking a balance between the two sides.

----------

