IMAP UIDVALIDITY reset: why a mailbox may need to be rescanned

Define the decision

IMAP UIDs are meaningful within a mailbox’s UIDVALIDITY context. Zintara’s reviewed synchronizer resets its last-seen cursor when that validity value changes, allowing the mailbox to be rescanned.

Work through the procedure

1. Confirm whether a provider migration or mailbox rebuild occurred.
2. Have an operator inspect the old and current validity values without exposing message contents.
3. Observe rescan progress and errors.
4. Check duplicate handling using stable message identifiers before attempting any manual recovery.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Before rebuild: UIDVALIDITY 100, last UID 900
After rebuild: UIDVALIDITY 200, message UIDs reassigned
Correct interpretation: UID 900 from the old namespace is not a safe new cursor
Zintara behavior: reset the cursor for a rescan

Read the result

A larger rescan can be expected after a namespace change. Repeatedly resetting state while it runs can create unnecessary work and complicate diagnosis.

Check before moving on

1. Check for concurrent sync attempts.
2. Verify a fresh controlled reply after the rescan.

Limits and next action

Messages without stable Message-ID values have weaker deduplication evidence. Do not assume a rescan provides exactly-once processing for every malformed historical message.

Source: RFC 9051: UIDs and UIDVALIDITY