Issue Dovecot IMAP extremely slow on large emails (UID FETCH > 90s)

[Danny3445]

Server operating system version

Ubuntu 24.04.3 LTS

Plesk version and microupdate number

Obsidian 18.0.71 Update #2

We’re running into major performance issues on our Plesk server when IMAP clients try to open large emails. Some messages (around 30–36MB) take over 90 seconds to load via IMAP (UID FETCH), even though the same message is read almost instantly using cat in the shell.

System info:

• OS: Ubuntu 24.04.3 LTS
• Plesk: Obsidian 18.0.71 Update #2
• Mailserver: Postfix + Dovecot (via Plesk)
• Filesystem: ext4 on SSD (/dev/vda1)
• Disk performance: ~511 MB/s (tested with dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=dsync)

Issue
When opening (large) messages (for example 35mb) are opened in clients like iOS Mail, iPadOS, or mobile email apps, loading via IMAP is extremely slow (25–90+ seconds). Oddly, this does not happen in Roundcube (webmail) or Outlook for Windows — they open the same emails quickly.

We suspect this isn't a client-side issue, though, because even when reading the same message over SSH using doveadm fetch, it takes equally long. However, when fetching the exact same message from the filesystem with cat, it returns in milliseconds.

What we tested:
1) Direct read speed (instant):

time cat /var/qmail/.../.Test/cur/... > /dev/null
→ real 0.007s

2) Dovecot IMAP fetch (very slow, tried on empty mailbox):

time doveadm fetch -u [email protected] text mailbox INBOX.Test uid 1
→ real 27.6s (in some case up to 90s+)

3) Moved mail to a clean test folder:
No performance difference.

4) Tried Dovecot config tweaks:
- maildir_very_dirty_syncs = yes → no noticeable improvement
- mmap_disable = yes → made it even slower
- mail_attachment_detection_options = add-flags → no effect
- Forced reindex with doveadm force-resync → no effect
- Indexing in custom path using :INDEX= → same performance

5) Mail count does not seem to be the problem:
Even in mailboxes with less than 1000 messages, large mails load just as slowly.

Example from logs:
Normal:

Disconnected: Connection closed (UID FETCH finished 0.019 secs ago) rcvd=189, sent=1410
Disconnected: Connection closed (UID FETCH finished 0.019 secs ago) rcvd=955, sent=3815
Disconnected: Connection closed (UID FETCH finished 1.227 secs ago) rcvd=1529, sent=10815

Not normal:

Disconnected: Connection closed (UID FETCH finished 93.437 secs ago) rcvd=11195, sent=59313632
Disconnected: Connection closed (UID FETCH finished 50.468 secs ago) rcvd=756, sent=1160928
Disconnected: Connection closed (UID FETCH finished 161.791 secs ago) rcvd=1438, sent=1811659

Question:
Why does Dovecot take this long to deliver large messages via IMAP, even though:
- The underlying file can be read instantly
- Disk I/O is very fast
- Maildir index files are in place
- The mailbox is small and clean

Is this a known issue with large MIME multipart messages? Or is there any Dovecot/Plesk-specific tuning required for better performance in these cases? I can't imagine this is normal on a very fast server.

We’d really appreciate any insights or solutions.

 

[trialotto]

We’re running into major performance issues on our Plesk server when IMAP clients try to open large emails. Some messages (around 30–36MB) take over 90 seconds to load via IMAP (UID FETCH), even though the same message is read almost instantly using cat in the shell.

System info:

• OS: Ubuntu 24.04.3 LTS
• Plesk: Obsidian 18.0.71 Update #2
• Mailserver: Postfix + Dovecot (via Plesk)
• Filesystem: ext4 on SSD (/dev/vda1)
• Disk performance: ~511 MB/s (tested with dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=dsync)

Issue
When opening (large) messages (for example 35mb) are opened in clients like iOS Mail, iPadOS, or mobile email apps, loading via IMAP is extremely slow (25–90+ seconds). Oddly, this does not happen in Roundcube (webmail) or Outlook for Windows — they open the same emails quickly.

We suspect this isn't a client-side issue, though, because even when reading the same message over SSH using doveadm fetch, it takes equally long. However, when fetching the exact same message from the filesystem with cat, it returns in milliseconds.

What we tested:
1) Direct read speed (instant):

time cat /var/qmail/.../.Test/cur/... > /dev/null
→ real 0.007s

2) Dovecot IMAP fetch (very slow, tried on empty mailbox):

time doveadm fetch -u [email protected] text mailbox INBOX.Test uid 1
→ real 27.6s (in some case up to 90s+)

3) Moved mail to a clean test folder:
No performance difference.

4) Tried Dovecot config tweaks:
- maildir_very_dirty_syncs = yes → no noticeable improvement
- mmap_disable = yes → made it even slower
- mail_attachment_detection_options = add-flags → no effect
- Forced reindex with doveadm force-resync → no effect
- Indexing in custom path using :INDEX= → same performance

5) Mail count does not seem to be the problem:
Even in mailboxes with less than 1000 messages, large mails load just as slowly.

Example from logs:
Normal:

Disconnected: Connection closed (UID FETCH finished 0.019 secs ago) rcvd=189, sent=1410
Disconnected: Connection closed (UID FETCH finished 0.019 secs ago) rcvd=955, sent=3815
Disconnected: Connection closed (UID FETCH finished 1.227 secs ago) rcvd=1529, sent=10815

Not normal:

Disconnected: Connection closed (UID FETCH finished 93.437 secs ago) rcvd=11195, sent=59313632
Disconnected: Connection closed (UID FETCH finished 50.468 secs ago) rcvd=756, sent=1160928
Disconnected: Connection closed (UID FETCH finished 161.791 secs ago) rcvd=1438, sent=1811659

Question:
Why does Dovecot take this long to deliver large messages via IMAP, even though:
- The underlying file can be read instantly
- Disk I/O is very fast
- Maildir index files are in place
- The mailbox is small and clean

Is this a known issue with large MIME multipart messages? Or is there any Dovecot/Plesk-specific tuning required for better performance in these cases? I can't imagine this is normal on a very fast server.

We’d really appreciate any insights or solutions.

@Danny3445

An elaborate analysis, thank you.

However, first try to establish what the source mail server is ........ since some of the mails originating from or relayed by Microsoft can cause hickups.

In addition, try to determine whether Postfix does not have to deal with a lot of connect/disconnect issues : inspect the maillog.

Finally, make a clear distinction between the clients, being

1 - the client subset consisting of Roundcube (webmail) and Outlook for Windows : no issues (this is to be expected)

2 - the client subset consisting of iOS Mail, iPadOS and mobile email apps : issues (to be expected if you test with mobile networks, but not to be expected if you test in a development or virtualized environment that is running on the server where the mail server resides)

and do some proper testing in order to exclude connectivity issues, taking into account that subset 1 (see point 1) works differently than subset 2.


I am pretty sure that it might be a client-side issue, given the nature of the subset of clients that you have issues with.

So, you will first have to rule out that client-side issues are factually absent - it is not sufficient to make an assumption that it is not client-side related.


I hope the above helps a bit!

Kind regards....

 

[Danny3445]

@Danny3445

An elaborate analysis, thank you.

However, first try to establish what the source mail server is ........ since some of the mails originating from or relayed by Microsoft can cause hickups.

In addition, try to determine whether Postfix does not have to deal with a lot of connect/disconnect issues : inspect the maillog.

Finally, make a clear distinction between the clients, being

1 - the client subset consisting of Roundcube (webmail) and Outlook for Windows : no issues (this is to be expected)

2 - the client subset consisting of iOS Mail, iPadOS and mobile email apps : issues (to be expected if you test with mobile networks, but not to be expected if you test in a development or virtualized environment that is running on the server where the mail server resides)

and do some proper testing in order to exclude connectivity issues, taking into account that subset 1 (see point 1) works differently than subset 2.


I am pretty sure that it might be a client-side issue, given the nature of the subset of clients that you have issues with.

So, you will first have to rule out that client-side issues are factually absent - it is not sufficient to make an assumption that it is not client-side related.


I hope the above helps a bit!

Kind regards....

Thanks for the detailed response! A few clarifications based on your suggestions:

We've confirmed that this is not just a client-side issue. Even when running:

doveadm fetch -u info@domain text mailbox INBOX.Test uid 1

...directly over SSH, fetching the message takes 10–90+ seconds, while a simple cat on the same mail file returns instantly. This rules out filesystem or disk performance issues.

The slow messages are not necessarily received from external sources, even mails sent from our own server can behave this way.

Mobile apps like iOS Mail behave differently, they initially fetch just headers, but load the full message only when a user taps it for the first time (fetch event like example above in SSH). That’s when the delay occurs.

At this point, it seems that the delay is caused by how Dovecot processes large multipart MIME messages during IMAP FETCH operations (especially those with images and or attachments), rather than due to client-side or disk performance issues.

We're happy to hear any additional ideas on how to optimize Dovecot for this use case.

 

[Danny3445]

Could mdbox solve the slow-loading large email issue — if Plesk supported it?

We've pinpointed that the slowness is not due to disk I/O or index issues, but rather how Dovecot processes large multipart MIME messages during IMAP FETCH operations.

Per cPanel’s documentation:

"Maildir is an older mailbox format that stores each email message as a file … mdbox is a high‑performance mailbox format that stores all email messages in a single file in each mailbox's folder and indexes the messages."

Given that mdbox often improves performance in environments with large mailboxes or heavy MIME parsing, would switching to mdbox likely resolve this performance bottleneck?

However, I realize Plesk does not officially support mdbox:

• Plesk GUI and mail setup are Maildir-centric
• You would need to manually configure mail_location and migrate existing mailboxes
• Quota visibility and other integrations may break or behave unexpectedly

So I’m asking:

1. Does anyone here have experience switching from Maildir to mdbox specifically on a Plesk-managed server?
2. Did switching to mdbox significantly improve IMAP FETCH performance, particularly with large, multipart messages?
3. What are the trade-offs in backup, index handling, and overall stability on Plesk when using mdbox?
4. Why does plesk not support it?

 

[trialotto]

@Danny3445

It can be rather simplified to the following golden rule : mail protocols are NOT intended as file transfer protocols.

Stated differently, one should not want to send to large messages, for many reasons.

The client-side might not even accept the large messages.

The server-side factually is able to easily send large messages.

In general, if you have a bottleneck somewhere, then it is often client-side - that is, in 9999 of 10000 cases.

There might be some tweaking that can be done with respect to Dovecot (or any other piece of similar software, like mdbox), but that still does not change the golden rule and the fact that most issues are client-side.

If you have - properly - ruled out other potential issues (connectivity issues, server resource usage issues, Postfix related issues), then one can safely state that the IMAP related issues are on the client-side.

Evidence of the latter statement has already been provided by the simple fact that you only have issues with a specific subset of clients - the common suspects, in the sense that they are not really designed to receive elaborate mails.

In summary, as opposed to working on the server-side, one can also consider to accept that one cannot do anything about client-side related issues.

I can only recommend that you stop tweaking dovecot or postfix - this might sound counterintuitive, but in some cases config tweaking will simply result in the opposite of the desired effect : the server will become less performant (or even become unresponsive).

It is a well-intended advice.

Kind regards.....