Send/Receive slow with imap, maybe only 1 customer

Richard G

Verified User
Joined
Jul 6, 2008
Messages
14,061
Location
Maastricht
Got message from a customer today, is a bit bigger customer with a bit more email usage, but nothing out of the ordinary.

The complaint is that sending and receiving goes slow. As far as I understood it, it's the connection between the client and the server. They are working on a cloud system from another company.
Customers employee said she sometimes have to push "send/receive" button so mail gets send more quickly. Otherwise it will get send, but takes a bit longer.
Other employee's are having the same issue.
At first I thought maybe the new Dovecot version maybe had something to do with this, but now I heard this was already an issue for several months, so the new Dovecot can not be cause. Which would be odd anyway because I can't find odd things in the logs.

My thought is that the cause is with the cloud provider connection in some way.

I checked logfiles but can't find any odd things, only this line regularly in the maillog.
Code:
Disconnected: Connection closed (IDLE running for 0.001 + waiting input for 4.878 secs, 2 B in + 10+2 B out, state=wait-input) in=650 out=19690 deleted=0 expunged=0 trashed=0 hdr_count=1 hdr_bytes=5926 body_count=1 body_bytes=6130

Somewhere else I read this is normal and can be ignored.

Anyone else having a kindlike issue or a clue on what can be the cause?
Customer is using imap and Office Outlook (don't know which version but probably not 365)
Server is Almalinux 9.6
RAM 65 GB from which 32 GB still totally free (rest is buff/cached and 9 gb really in use and 7 gig shared)
Swap is 4 GB but 0 used
CPU Intel(R) Core(TM) i7-6700

Top c gives this:
Code:
top - 14:20:18 up 3 days, 13:22,  3 users,  load average: 0.26, 0.38, 0.49
Tasks: 307 total,   1 running, 306 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.7 us,  1.6 sy,  0.0 ni, 96.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  63819.4 total,   3294.6 free,   9277.5 used,  52621.9 buff/cache
MiB Swap:  32735.0 total,  32735.0 free,      0.0 used.  54541.8 avail Mem
 
Well, everything looks ok, but outlook isn't that good with imap and big mailboxes or many submaps. So when outlook is busy with all his maps this might block the automatic send/receive every now and then.
Maybe they use the outlook cached mode? Cool for exchange, crappy for imap.
You can enable mail_debug, see if it really takes long between a connect/fetch'.
Or.... just say it's their dns.
 
So when outlook is busy with all his maps this might block the automatic send/receive every now and then.
Thank you. Is that with all Office Outlook versions or is that issue fixed in certain newer versions?

They do have a lot of mailboxes. So for example 1 mail address which is used a lot, has 109 INBOX.some name folders, where the "some name" are ofcourse different names. That is a whole lot indeed.
Next to that some local boxes of their own, not that many, like 18.

The other accounts don't have that many folders. The other big one has no "INBOX.some name" folders but just like 11 local folders.

Maybe they use the outlook cached mode?
Where can this be found in Outlook? Then I can have a look if I can turn that off.
Odd thing is that this has always been working fine, just since several months it does not. A few months ago they couldn't do anything anymore and then the cause was that they passed their limit for the Cloud provider.
My good guess is that the issue has started around since then.

Now I see something else in the log (from another user with an auto forward to gmail which was blocked by gmail, but on our system returning the mail now I see this:
Code:
550-Rejected because 138.201xxx.xxx (our server ip) is in a black list at zen.spamhaus.org\n550 Error: open resolver; https://check.spamhaus.org/returnc/pub/35.180.1.28/
However when I check at spamhaus, both ip's give "no issues" as a result.
Also on other spam checkers the ip's are not in any blacklist. So very very odd that this is now showing this way in the exim mainlog.

Anyway, that's a different thing. This does not go for the original issue and we are not on any blacklists.

I can indeed try to use mail_debug however, seems only they have an issue, not other customers.
 
It might not be it, but give it a shot:
Thanks I will tell them that.

Hahaha hoarders. LoL. :D
But you're right. In this case it's an administration company, they do tax administration for people and some businessess. And this one with the 109 folders is doing payroll administration for company('s) hence the lot of folders.

Anyway, as long as it's not my fault I'm happy.:)
 
Well, there are a few things tweakable in dovecot but things also tent to increase in difficulty with growth. We also notice a lot of issues lately regarding outlook and hotmail domains, even "you're on a blacklisted blabla' even though that server, according to sdns, is as clean as a virgin.
Kinda smell's like a 'wanna bet it works if you buy mickysoft 365' ad.

BTW, you're from my hometown, sjeng :)
 
Last edited:
Oh nice. I thought you were 'ne Hollènder. :)
You're not Erik by any chance right?

@gate2vn I will tell that to them, luckily I don't manager their servers and cloud so the cloud company that takes care of that needs to check. :)
Nope, John here, that's between a regular Erik and 1 blazingly good Erik :)
 
Hmmz... seems this issue is on more of our servers with multiple userse, also users with few or no custom folders.
I'm wondering if there is a way to speed up the connect. Once it's made it looks like everyting is handled fast enough. But seems there are delays with connections to the servers.
They are Hetzner servers, but issue is with servers in Germany and in Finland, so different datacenters, differente routes.
I don't have any issues at all, but I almost don't use imap.

I checked and we're not running into low memory or max connections per ip.

I will try debug and see if that shows anything.

Seen this in debug mode, I presume this is normal?
Code:
Debug: sieve: storage: Default script not found
Debug: sieve: User has no personal script
Debug: sieve: No scripts to execute: reverting to default delivery.
Debug: duplicate db: Cleanup
and then the mailbox get's opened and mail delivered.
 
Last edited:
See a lot of these too, permission denied?
Code:
Jun 17 19:08:18 lmtp(3702464): Error: conn unix:/run/dovecot/anvil (pid=965,uid=0): net_connect_unix(/run/dovecot/anvil) failed: Permission denied
Jun 17 19:08:18 lmtp(3661322): Error: conn unix:/run/dovecot/anvil (pid=965,uid=0): net_connect_unix(/run/dovecot/anvil) failed: Permission denied
Jun 17 19:08:18 lmtp(3443069): Error: conn unix:/run/dovecot/anvil (pid=965,uid=0): net_connect_unix(/run/dovecot/anvil) failed: Permission denied
Jun 17 19:08:18 lmtp(3161524): Error: conn unix:/run/dovecot/anvil (pid=965,uid=0): net_connect_unix(/run/dovecot/anvil) failed: Permission denied
Jun 17 19:08:18 lmtp(3791436): Error: conn unix:/run/dovecot/anvil (pid=965,uid=0): net_connect_unix(/run/dovecot/anvil) failed: Permission denied
Jun 17 19:08:18 lmtp(3464588): Error: conn unix:/run/dovecot/anvil (pid=965,uid=0): net_connect_unix(/run/dovecot/anvil) failed: Permission denied
Jun 17 19:08:18 lmtp(3161524): Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)
Jun 17 19:08:18 lmtp(3661322): Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)
Jun 17 19:08:18 lmtp(3582549): Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)
Jun 17 19:08:18 lmtp(3782110): Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)
Jun 17 19:08:18 lmtp(3760932): Error: conn unix:/run/dovecot/anvil (pid=965,uid=0): net_connect_unix(/run/dovecot/anvil) failed: Permission denied
 
check if the socket exists:
# ls -l /run/dovecot/anvil

check user under which the process runs with:

# ps aux | grep lmtp

anvil should be running as root iirc.
 
That seems all allright to me.
Code:
# ls -l /run/dovecot/anvil 
srw------- 1 root root 0 Jun 17 19:34 /run/dovecot/anvil

Code:
# ps aux | grep lmtp
hosting+ 3973010  0.0  0.0  22324 14720 ?        S    19:34   0:00 dovecot/lmtp [local READY]
root     3973011  0.0  0.0  16388 11136 ?        S    19:34   0:00 dovecot/lmtp 
root     3973013  0.0  0.0  16388 11008 ?        S    19:34   0:00 dovecot/lmtp 
root     3973014  0.0  0.0  16388 11136 ?        S    19:34   0:00 dovecot/lmtp 
maxxx    3973018  0.0  0.0  22452 15056 ?        S    19:34   0:00 dovecot/lmtp [local READY]
maxxx    3973019  0.0  0.0  22440 15096 ?        S    19:34   0:00 dovecot/lmtp [local READY]
root     3973020  0.0  0.0  16388 11136 ?        S    19:34   0:00 dovecot/lmtp 
latxxx+ 3973021  0.0  0.0  22800 15412 ?        S    19:34   0:00 dovecot/lmtp [local READY]
root     3973022  0.0  0.0  16388 11008 ?        S    19:34   0:00 dovecot/lmtp 
maxxx    4011411  0.0  0.0  22452 15252 ?        S    19:43   0:00 dovecot/lmtp [local READY]
bigcus+ 4062917  0.0  0.0  22672 15328 ?        S    19:55   0:00 dovecot/lmtp [local READY]
root     4074307  0.0  0.0  16388 11264 ?        S    19:58   0:00 dovecot/lmtp 
root     4092521  0.0  0.0  16388 11264 ?        S    20:02   0:00 dovecot/lmtp 
root     4105675  0.0  0.0  16388 11392 ?        S    20:05   0:00 dovecot/lmtp 
root     4125380  0.0  0.0  16388 11264 ?        S    20:10   0:00 dovecot/lmtp 
root     4141160  0.0  0.0  16388 11264 ?        S    20:14   0:00 dovecot/lmtp 
root     4155724  0.0  0.0   6408  2304 pts/0    S+   20:17   0:00 grep --color=auto lmtp
 
As a side note when sending email I have noticed that slow to respond DNS resolver setup on the server has a noticeable impact on how responsive the sending process is from the email client.
 
I'm using a local resolver on the server, so the server itself, so 127.0.0.1 as first resolver.
Second resolver is from datacenter and third resolver is 1.1.1.1.

I required this local resolver so at first I wouldn't run into spam check request limitations.
But that is not the problem. I checked and monitored the logs and once the connection is made, the mail is send and delivered within 2-3 seconds.
Same for reception of mails.

It's the connection of the email client with the server, so before mail is send or received which is the issue as it seems.
And it also looks like it's only with imap.

I'm having like 19 accounts on the server for company and hobby, all pop3 and no issue's whatsoever.
 
Back
Top