Send/Receive slow with imap, maybe only 1 customer

[Richard G]

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.

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:

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

 

[sysdev]

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.

 

[Richard G]

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:

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.

 

[sysdev]

It might not be it, but give it a shot:

Turn on Cached Exchange Mode - Microsoft Support

Use Cached Exchange Mode for quick access to your Exchange account information even when a server connection is not available.

support.microsoft.com

109 is a lot indeed. Takes time to sync I guess. But having 'a lot' of anything is always a hassly, cloud or local. Damn hoarders...