Outlook IMAP send/receive extremely slow after Zimbra → Carbonio CE migration (server-side fast, 500x throughput drop across VLAN)

Environment

• Carbonio CE (Ubuntu 24.04), single-server install, ~200 accounts, 4 domains
• Migrated from Zimbra FOSS 8.8.15 via imapsync, ~1.5 TB
• AD authentication (zimbraAuthMech: ad, per-account zimbraAuthLdapExternalDn)
• Network: Carbonio at 10.10.34.37, mail gateway (Symantec SMG) at 10.10.34.38, FortiGate between VLANs
• Wildcard commercial cert (RapidSSL), deployed via zmcertmgr deploycrt, verified on 443/993/25
• NIC: vmxnet3 (same as old Zimbra VM)

Old Zimbra server is still up on 10.10.34.36, same VLAN, same FortiGate — no network changes were made during migration.

Symptom

Outlook (IMAP, 16.0.20326) send/receive takes minutes instead of seconds. Users report "mail arrives only after closing and reopening Outlook". Webmail is fast. Mobile clients (IMAP) work fine. Same Outlook clients had no issue against Zimbra on the same network.

Affects users from the office network (NAT'd behind 212.125.30.10) and also from other networks (mobile hotspot).

What we measured

IMAP protocol on the server is fast. From mailbox.log, a full Outlook session (login, XLIST, SELECT on 6 folders, UID FETCH) completes in ~2 seconds with elapsed=0..119ms per command. No errors.

Raw TCP throughput test (python3 http.server, 50 MB random file, no TLS/nginx/IMAP involved):

500x drop when crossing the FortiGate. TCP handshake and SSL handshake to 993 from the same PC complete in 8–100 ms — only bulk transfer is slow.

nginx proxy log

removed link shows ~140 entries/day of:

SSL_write() failed (SSL: error:80000020:system library::Broken pipe:tls_retry_write_records failure) (32: Broken pipe) while proxying, client: 212.125.30.10:60262, server: 0.0.0.0:993

always immediately after proxied session done for the same session ID. tcpdump confirms RST comes from the client side. I believe this is the known benign "write after client close" message (same pattern reported on nginx list in 2008 by Zimbra), not the root cause — mentioning it for completeness.

What we ruled out (no change in behavior)

• ufw default incoming set to allow — no difference
• fail2ban stopped — no difference; user IPs were never in ban list
• TCP offload disabled (ethtool -K ens33 tso off gso off gro off lro off) — no difference (68 s vs 51 s)
• imap_authenticated_max_idle_time is 1800 s, proxy_timeout 2100 — not a timeout issue
• Certificate chain verified on 443/993/25 (zmcertmgr verifycrt OK, openssl s_client shows RapidSSL on all three)
• zimbraImapMaxConnections raised 200→1000, zimbraImapNumThreads 200→500
• DNS resolves consistently to the public IP from all client networks
• IP not on any blacklist
• Memory: 31 GB total, ~5 GB swap in use (MariaDB 7 GB RSS, mailbox JVM 6.4 GB) — noted but localhost throughput test shows no CPU/disk bottleneck

Question

Given that:

• server-side IMAP is fast,
• same-VLAN throughput is full speed,
• cross-VLAN throughput drops 500x,
• the old Zimbra on the same VLAN and same FortiGate did not have this problem,

is there anything in Carbonio's TCP/nginx behavior (socket options, window scaling, so_keepalive, tcp_nodelay, proxy buffering) that differs from Zimbra 8.8.15 and could interact badly with an intermediate firewall doing deep inspection? Or should we treat this purely as a FortiGate policy issue and stop looking at Carbonio?

Any pointers on what to capture next would be appreciated.

Versions:

carbonio-appserver 4.5.1-1noble
carbonio-mta       4.2.8-1noble
carbonio-proxy     4.14.4-1noble