Prolonged 'Waiting for server response'

I am running a small-scale mail server for an organisation. The company has around 15-20 users on a local network (meaning all connecting to the server via a single public IP). Some of the mail users are complaining about “Waiting for server response” in their Outlook mail client. Since the mail is for internal communication mostly the server chosen is also low grade with 2 vCPUs and 4 GB RAM.

I’ve tested the server itself when the company is having this issue. The server does not seem to be overloaded. The SSH and the webmail are functioning normally. Its slow sometimes however never unresponsive.

I’ve also set the mail server limits as mentioned in another topic named Mailserver Limits

I am unable to see any connection drops although I do get some warnings as below but no “client connections are being dropped” errors.

master: Warning: service auth { client_limit=1000 } is lower than required under max. load (2500). Counted for protocol services with service_count != 1: service managesieve-login { process_limit=500 } + service pop3-login { process_limit=500 } + service lmtp { process_limit=500 } + service imap-urlauth-login { process_limit=500 } + service imap-login { process_limit=500 }

I’m guessing that since all 15-20 users have the same public IP there must be some sort of limit being applied… BUT WHERE… I can’t seem to figure out. Is it imap, smtp, firewall?

Any help in this regards will appreciated.

Is no body here to read or respond? Did I make a mistake choosing MIAB as a solution to implement?

Hello

Your post seems to have just turned up, anyway if you ssh to the server and tail -f /var/log/mail.log do you see the outlook clients making a connection to pick up the email?

I found this it may help:

  • client_limit should be large enough to handle all the simultaneous connections. Dovecot attempts to verify that the limit is high enough at startup. If it’s not, it logs a warning such as:
  • Warning: service auth { client_limit=1000 } is lower than required under max. load (1328)
    This is calculated by counting the process_limit of every service that is enabled with the “protocol” setting (e.g. imap, pop3, lmtp). Only services with service_count != 1 are counted, because they have persistent connections to auth, while service_count=1 processes only do short-lived auth connections.

Thanks for the message… Yes I do see clients connecting in the logs… and I’ve already increased the client_limit to 3000 but even before that, as I mention, I am not seeing any connection drop messages in the logs. How do I know clients are being dropped or refused connections? mail.log certainly does NOT show any dovecot drop connection errors. How can I further debug this?

What I would do in this situation would be to create a VirtualBox say running Ubuntu desktop and install Thunderbird, setup at test account on MIAB and using IMAP to connect see if you run into the same issue as Outlook (still checking the logs). We need to establish if we are investigating an Outlook or MIAB issue, just seems odd that it’s never popped up before.
The whole thing should only take about 20-30mins.
Let us know the result.

I’ve already done that up to some extent. I set up client addresses in outlook on 1 PC in our office. We did not experience any connection drops. I’ve already asked the client to try different mail clients like Thunderbird and see if its an outlook issue. I’m yet to hear a word on this from them. Client on the other hand has around 15 20 PCs with different clients behind a single IP… Its not practically possible for me to replicate the client’s environment, i.e. configure all client accounts on 20 different virtual machines.

So while the client changes their mail clients to test, I need to make sure that the connections are not being dropped from the server side. As mentioned, I don’t see any connection drop errors in the mail.log, nor do I find the client IP address in the fail2ban temp or permanently banned IPs list. Where else could the problem lie on the server? Maybe dovecot is not logging properly? Maybe something else other than fail2ban is limiting the IP? Maybe I’m not looking at the right logs?

Just a thought:- is your clients internet connection stable?

run netstat -i as root on the MIAB and check for dropped packets:
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
ens192 1500 151050 0 0 0 444658 0 0 0 BMRU
lo 65536 180238 0 0 0 180238 0 0 0 LRU
wg0 1420 0 0 0 0 0 0 0 0 OPRU

or netstat -s (shows the stats) look for Tcp section

Perhaps this has something to do with anvil authentication penalty? See Authentication penalty support — Dovecot documentation
From some quick searching I could not yet gather what the default settings are, it might not be enabled by default.

Hey nadir

Any success in finding and dealing with your issue?