I did some research but nothing just straight about improving SMTP connection on qmail when sending an email. Just a note about using dnscache from djdns that I assume is already working by default on Interworx servers.
I know some time ago you could do some tricks on Plesk control panel to improve mail connection when sending out mails, related to DNS / ident lookups, and that really did improve performance when sending out a single email.
The fact is I notably notice some type of two-three seconds ‘detention’ when my email client connects to my Interworx-qmail SMTP server, for a single email reply, and I’m wondering what’s related to… (SMTP auth? just a DNS lookup?).
(I’m using Thunderbird on WinXP, but it just sends mail faster through other SMTPs)
I have similar issues with the initial response time on the SMTP server as well, but I’m using Entourage on a Mac (I’ve tried other email clients as well). We have an Ensim server as well with almost identical hardware specs and the mail goes out almost instantly. With the Interworx server, there’s a 1 to 3 second delay when ouy click the send button.
Mind you, in every other way, I find Interworx to be better across the board and much prefer it to Ensim.
If anyone has some thoughts as to how to cut down on the delay, I’d certainly be appreciative as this is the one little issue I haven’t been able to resolve.
I agree on prefering Interworx for several reasons, despite this little discomfort. Anyway, and althought is not my case on having shared-clients, I’m sure webhost customers tend to complain about little things like this “1-3 seconds to get email server to respond”.
Yes, I’m afraid we live in an instant gratification society…
It probably wouldn’t be an issue if they hadn’t been on the Ensim box previously and when I migrated them to the Interworx system they immediately noticed the speed difference sending mail.
Other than that, they all seem to agree that the panel is MUCH better. Hopefully we’ll get some guidance on this one and can put it to bed with the users.
Do you guys have SMTP Level Spam Scanning enabled? If so, this would explain the delay when sending mail, if the message has to be scanned by SpamAssassin before it decides to accept the mail.
What is the contents of your /etc/resolv.conf file? If there are any dns servers listed in there that are invalid it could definitely slow down lookup times. Try making the contents of that file just
nameserver 127.0.0.1
if it isn’t already.
If that doesn’t help, what happens if you telnet to port 25 from a dos window/terminal?
telnet ipaddress 25
Do you see any delay and receiving the SMTP banner? Is it similar to the delay when sending?
Are you sure? I think he is talking about the delay when the email proggie says “Connecting to…”. That is before the message is transfered to the server.
Edit: I’m jumping in because we also have this problem, and have with every host we have ever used. InterWorx does it too, but before we purchased InterWorx, our Postfix setup did not have the delay. We were pleased that emails would send instantaneously, but with qmail, there is a 3 second delay before the mail server will even respond.
[SIZE=2]Same here, and thanks for stopping by Paul.[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]I’ve looked and I even had stopped clamAV and SpamAssassin.[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]I have also just[/SIZE]
cat /etc/resolv.conf
nameserver 127.0.0.1
[SIZE=2][/SIZE]
[SIZE=2]On Thunderbird, the 2-3 seconds delay comes while “Connected to mail.mydomain.tld” message is up, not while ‘connecting’[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]Interworx account has spam control ‘off’ too.[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]On Nodeworx MTA settings, mail server hostname is a domain that resolves and such.[/SIZE]
[SIZE=2]I’ve tried to restart SMTP inbound & outbound after disabling more things and it performs the same.[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]The only thing I can think of is that I’m serving DNS zones offsite, through a third-party service (zoneedit.com). My DNS Server settings on Nodeworx have the usual Sago DNS defaults (ns1.cust.sagonet.com, ns2…)[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]Can this DNS behaviour somehow produce that delay?[/SIZE]
Could qmail be doing a reverse DNS lookup, maybe for logging purposes?
I considered the possibility of qmail imposing a rate limit, for the purpose of preventing mail server abuse, but then I realized that my server-side applications (shopping carts) that need to send a lot of emails can do it instantly (I wrote the code myself, so I know there isn’t an application-level mail queue involved :)) – with separate connections between each email and not even a delay on the first.
Based on what I just described, I have to think it is something that only triggers for outside connection requests.
Oops. My message about about “Connecting to…” should have been “Connected to…” (just like your’s). The mail server acknowledges the connection immediately, but there is a 2-3 delay before the sending process (which is also instant after it begins).
You know Jim, you may have something with that. Years ago I ran into a similar problem installing qmail on a client’s Linux server. The send time was very long (15 sec) until I set the qmail option to not do reverse lookups. After that, all worked fine.
In the e-mail client, change the outgoing mail server to be the IP address instead of the domain name. If that eliminates the delay, it’s safe to say the delay is related to DNS lookups of the domain itself somehow.
You could also try sending a message via telnet, and try to determine at what point the delay occurs, that might help track it down.
# replace ipaddress with your server's IP address (hostname is valid here also)
# replace you@yourdomain.com with your e-mail address
# note that the RCPT TO below should be an e-mail address on the server.
telnet ipaddress 25
HELO test
MAIL FROM: you@yourdomain.com
RCPT TO: you@yourdomain.com
DATA
asdf
.
quit
And just to thwart anybody that starts an open relay discussion here, if you’re doing this test on your server you’re already authenticated via pop/imap before smtp, so no, it’s not a sign of an open relay. I promise.
The DNS lookup isn’t a problem, it gets the resolution almost instantly. As for the Telnet test, it worked quickly but that makes me wonder about something…
In my email client I have it set to authenticate to the SMTP server prior to sending. Would the additional authentication slow things down enough to show the lag we’re seeing? Just a thought.
The -H (no lookups) parameter did not fix my problem.
I had SMTP authentication enabled (w/o TLS). Simply not using SMTP authentication (not sending a user/pass) appears to have fixed the problem. Now clicking “Send” delivers the message very quickly.
Does not having SMTP auth cause any problems? I used to think the mail server required it, but obviously not.