Deepin Mail automatic IMAP checks take ~56 seconds due to five serialized requestRecentHeaders operations

[svan71]

SUMMARY | 问题概要

Deepin Mail automatic and startup IMAP checks take approximately 56 seconds even when there is no new mail. The UI spinner is not falsely stuck: it accurately reflects five serialized requestRecentHeaders operations, each taking about 11 seconds.

The same Comcast/Xfinity IMAP account checks quickly in macOS Mail. A direct credential-free transport test from the affected Linux machine also completes DNS, TCP, TLS, server greeting, and IMAP CAPABILITY negotiation in about 0.14 seconds, so basic network and TLS setup are not responsible for the 56-second delay.

SOFTWARE/OS VERSIONS | 软件/系统版本信息

• Deepin Mail: 6.5.75 / official 6.5.75.1 application build
• Instrumented package: deepin-mail-bin 6.5.75-3, unmodified application binary
• Application Build ID: e894d6a89180cb4ba71f418d831366320ff57c31
• Desktop/session: Deepin/Treeland (Wayland)
• Account type: Comcast/Xfinity IMAP
• The user observed the same slow behavior in Deepin and in an Arch Deepin/Treeland environment using the same Mail application generation.

PRE-REQUIREMENT | 预置条件

1. Configure a working Comcast/Xfinity IMAP account in Deepin Mail.
2. Set automatic mail checking to every three minutes.
3. Ensure the account can successfully receive, delete, and synchronize messages.

No authentication failures occur; mail eventually synchronizes correctly.

STEPS TO REPRODUCE | 复现步骤

1. Close Deepin Mail.
2. Open Deepin Mail and observe the startup mail check.
3. Leave Mail open without pressing the manual Send/Receive button.
4. Wait for at least two automatic three-minute checks.
5. Observe the checking-mail spinner duration for startup and each scheduled check.

OBSERVED RESULT | 观察到的结果

A clean 600-second trace captured the following:

• Startup check: approximately 56.003 seconds.
• First later check: approximately 56.004 seconds.
• Second later check: approximately 56.004 seconds.
• Each completed normally and cleared the spinner.
• The request counter remained positive for the entire busy period.
• There was no counter-zero worker-thread tail and no falsely latched spinner.

A second timestamp-only trace isolated the behavior:

• Each check issues five requestRecentHeaders operations serially.
• Each operation takes approximately 11.19–11.63 seconds.
• Each operation opens one or more TLS connections.
• Connection setup and the initial write occur in roughly 0.1 seconds.
• Each operation then has an approximately 8.6–11.4 second gap before the response is consumed.
• Five sequential waits produce the approximately 56-second total.

Independent credential-free Comcast IMAP transport tests from the same machine:

Run	DNS + TCP + TLS + greeting + CAPABILITY
1	142.8 ms
2	143.7 ms
3	138.5 ms

No credentials, message content, account address, or private server data were captured.

EXPECTED RESULT | 期望的结果

Automatic and startup checks should complete promptly when the server is reachable and there is little or no new mail.

Deepin Mail should reuse a persistent authenticated IMAP connection where possible, or avoid executing five slow header requests serially. A provider-specific response delay should not be multiplied five times into a roughly 56-second UI operation.

ADDITIONAL INFORMATION | 额外补充

The spinner itself appears correct and should not simply be suppressed. The performance problem is in the underlying receive path.

The evidence suggests investigating:

• why five requestRecentHeaders operations run sequentially;
• why repeated TLS connections are created during one check;
• whether an approximately 11-second timeout or delayed completion occurs for each request;
• whether connection reuse, batching, or parallel execution would avoid multiplying the delay.

A redacted event timeline and aggregate diagnostic data can be provided if needed.