IMAP IDLE reconnects: how to avoid missed cold-email replies after a timeout

IDLE does not remove the need for synchronization

IMAP IDLE lets the server send mailbox updates while the client waits, which reduces polling latency. It does not make the network connection permanent. Servers, NAT devices, proxies, laptop sleep, deploys, and process restarts can end the session. A production reply detector should therefore separate two jobs: discovering that something changed quickly and synchronizing mailbox state correctly. IDLE handles the first job while connected; UID-based catch-up handles the second after any interruption.

Detect dead sessions explicitly

Your IMAP library may emit close, error, timeout, or end events, but do not assume one callback covers every failure mode. Configure connection timeouts and heartbeat behavior according to the library and provider. Track the timestamp of the last successful server interaction. If the session exceeds an expected idle lifetime without traffic, end it deliberately and reconnect. A stuck socket that produces no exception can be more dangerous than a clean disconnect because monitoring may still report the process as alive.

Reconnect by reselecting the mailbox

After reconnecting and authenticating, SELECT or EXAMINE the intended mailbox again and capture UIDVALIDITY and UIDNEXT. Do not continue using the old selected-state assumptions from the previous TCP session. Compare UIDVALIDITY with the saved value; if it changed, trigger the full resynchronization path. If it matches, search for UIDs greater than the last safely processed UID and fetch those messages before starting a fresh IDLE cycle.

Catch up before waiting again

The race window is the time between the last message processed on the old connection and the moment the new IDLE session becomes active. A reply can arrive during that gap. If the client reconnects and immediately enters IDLE without an incremental search, no new event may be emitted for a message that already exists. The catch-up query closes that gap. Only after processing all unseen-by-cursor UIDs should the worker return to notification mode.

Do not use the \Seen flag as the cursor

A human may open a reply in webmail while your worker is disconnected, which changes \Seen. If reconnection logic searches only UNSEEN, it can miss a message that was never processed by automation. Keep your own processed UID cursor or event store. You can read content with methods that avoid setting \Seen, but the critical design principle is independence: human read state and automation processing state are different pieces of information.

Make reconnect loops bounded and observable

If authentication fails or the provider is unavailable, an unbounded tight reconnect loop can hammer the service and flood logs. Use exponential or staged backoff with a ceiling, and expose a health metric for how long the mailbox has been disconnected. Alert when that duration exceeds the maximum window in which a reply should cancel follow-ups. The goal is not instant reconnection at any cost; it is reliable recovery without turning an outage into another rate problem.

Coordinate with follow-up cancellation

When the reply worker is disconnected, your sequence scheduler should know mailbox evidence may be stale. For a high-value or low-volume campaign, you can add a safety check before sending the next follow-up: run a quick catch-up for the mailbox if its reply detector has been offline beyond a threshold. This reduces the chance of sending “just following up” to someone who replied during an IMAP outage. The appropriate guard depends on scale, but the state should be visible across components.

Test a forced disconnect

A staging test should open IDLE, receive one message, then forcibly close the connection. Deliver another reply while the worker is offline, allow reconnect, and verify that the catch-up search processes the missed message exactly once before IDLE resumes. Also test process restart with a persisted cursor. If these scenarios pass, the system is much closer to real mailbox reliability than one that only demonstrates live IDLE notifications on a stable connection.

Use IDLE as a wake-up signal and UID sync as the source of truth

An IDLE connection can disappear because of NAT timeouts, server policy, network changes, or application restarts. The safe architecture does not assume every EXISTS notification will be observed. Treat IDLE as a low-latency hint that tells the worker to run synchronization; after reconnecting, reselect the mailbox, validate UIDVALIDITY, and fetch all UIDs above the durable cursor. This catch-up step closes the gap between the last confirmed processed message and the current mailbox even when the connection died silently for several minutes.

Instrument the reconnect loop with timestamps that answer three questions: when was the last server activity, when was the last successful mailbox sync, and how far is the UID cursor behind. A worker that reconnects constantly but still advances the cursor may have a network problem; a worker with a stable socket but a frozen cursor has a different failure. Backoff repeated connection failures so one mailbox cannot spin aggressively, and make reply side effects idempotent so reconnect catch-up is safe to rerun. The operational test is simple: open IDLE, forcibly drop the TCP session, deliver a reply while the worker is offline, and prove that the reply is ingested and its scheduled follow-up is cancelled after reconnection.

Field checklist

• Treat IDLE as notification, not durable state.
• Persist a UID-based processing cursor outside the IMAP session.
• On reconnect, reselect INBOX and compare UIDVALIDITY.
• Run a catch-up search before re-entering IDLE.
• Do not use UNSEEN as the automation cursor.
• Test a forced disconnect with a reply arriving during downtime.