Bug Report: UIDVALIDITY=0 causes IMAP connection failure with WinWebMail

[fuukliam]

Description
Himalaya fails to fetch emails from IMAP servers that return UIDVALIDITY 0 in the SELECT response. This occurs with WinWebMail 4.4.0.1, which violates RFC 3501 by returning 0 instead of a positive integer.

Environment

• Himalaya version: v1.1.0
• OS: macOS 15.7.3 (arm64)
• Email server: WinWebMail 4.4.0.1
• IMAP host: mail.xwtec.cn:143 (also tested 993 with SSL)
• Backend type: IMAP (unencrypted and SSL)

Steps to Reproduce

1. Configure Himalaya with an account on WinWebMail server
2. Run himalaya envelope list
3. Observe error

Actual Behavior

Error: 
   0: cannot fetch IMAP messages
   1: cannot resolve IMAP task
   2: unexpected NO response: failed

IMAP Session Log

S: * OK IMAP4 on WinWebMail [4.4.0.1] ready.
C: A1 LOGIN heguanglei10857 ***
S: A1 OK LOGIN Completed
C: A2 SELECT INBOX
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Recent)
S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen)] Limited
S: * 233 EXISTS
S: * 73 RECENT
S: * OK [UIDVALIDITY 0] Ok          <-- Problem here
S: * OK [UIDNEXT 3014] Predicted next UID
S: A2 OK [READ-WRITE] Ok

Expected Behavior

Himalaya should tolerate UIDVALIDITY 0 and continue processing, treating it as if it were 1 (or any valid positive integer).

Workaround

Other email clients (Foxmail, Outlook, Apple Mail) handle this gracefully by ignoring or converting the invalid value. Currently using these alternatives as a workaround.

Suggested Fix

Add a --tolerate-nonstandard flag or automatically handle UIDVALIDITY 0 by converting it to 1 internally.

Additional Context

• RFC 3501 specifies UIDVALIDITY must be a positive integer
• WinWebMail is widely used in enterprise environments in China
• This affects many users who cannot change their mail server configuration

[soywod]

@duesee have you heard about this before? Does it justify the implementation of another quirk?

[duesee]

Hm... We know about a similar issue: modern-email/defects#22 In that issue, the UIDVALIDITY exceeds u32::MAX. The situation here could be simpler because we could allow 0. However, if we do so, I would want to fully make sure we never produce UIDVALIDITY 0. Another way could be to treat UIDVALIDITY 0 as having no UIDVALIDITY at all. Maybe this would reflect better what the server is doing? @fuukliam, would you mind to report this here, too? https://github.com/modern-email/defects

At some point maybe we should try to contact all these providers before band-aiding everything.