How to read email over IMAP without marking it as seen
Use a fetch form that does not implicitly set the \Seen flag when the automation should inspect a message without changing the human inbox state.
Read field note →IMAP operations
Reply detection and mailbox cleanup run on IMAP, and IMAP has sharp edges: UIDs versus sequence numbers, UIDVALIDITY resets, folder-name and delimiter differences across providers, and IDLE reconnects that drop replies. These notes show how to read mail without marking it seen and how to build automation that degrades safely.
New to this? Start with the pillar guide: Reply detection and follow-up state for cold email
Why IMAP Trash and Junk folder names break across languages and providers
Display names are not portable identifiers; providers can expose localized or vendor-specific mailbox names.
Read field note →
IMAP UID vs. sequence number: use the right identifier in automation
Message sequence numbers can change as the mailbox changes; UIDs are designed to remain stable within a UIDVALIDITY epoch.
Read field note →
How to batch-delete IMAP messages without turning cleanup into data loss
Deletion is normally a flagging operation followed by expunge semantics; automation should define exactly which messages are eligible before removal.
Read field note →
How to make cold-email reply detection idempotent
A reply processor should be safe to run twice: the second pass must not create a second reply event, cancel the same sequence twice or resurrect follow-ups.
Read field note →
What to check when IMAP folders suddenly disappear
Missing folders can be a namespace, subscription, permission or provider-mapping issue; it is not always deletion.
Read field note →IMAP UIDVALIDITY changed: how a reply detector should rebuild its cursor safely
IMAP UIDs are only stable within a mailbox while UIDVALIDITY remains the same. If UIDVALIDITY changes, cached UIDs from the old validity value can no longer be trusted as identities in the new mailbox state.
Read field note →IMAP IDLE reconnects: how to avoid missed cold-email replies after a timeout
IMAP IDLE can notify a connected client about mailbox changes, but TCP sessions and servers can drop. Reply detection needs reconnect and catch-up logic instead of assuming one IDLE session lives forever.
Read field note →IMAP mailbox is read-only: why delete or EXPUNGE appears to succeed but nothing disappears
IMAP distinguishes read-write and read-only selected mailboxes. If a mailbox is opened with EXAMINE or the server grants only read-only access, permanent state changes and expunge behavior are restricted.
Read field note →How to parse multipart/report delivery-status bounces without relying on the subject line
Standard Delivery Status Notifications can use multipart/report with a message/delivery-status part that carries structured per-recipient fields. Parsing that structure is more reliable than matching “Undeliverable” in the subject.
Read field note →Auto-Submitted: auto-replied is a better out-of-office signal than subject matching alone
RFC 3834 recommends Auto-Submitted: auto-replied for automatic responses. It is a strong signal for vacation and automatic replies, but real systems still need a layered classifier because not every provider follows the standard perfectly.
Read field note →Why IMAP SEARCH UNSEEN is unsafe as the only cold-email reply detector
UNSEEN describes mailbox read state, not whether your automation processed a message. Human activity, mobile clients, filters, and other workers can change the Seen flag before your reply detector runs.
Read field note →IMAP UIDNEXT is a hint, not the UID of the next reply: use it correctly in polling
UIDNEXT predicts the next UID value assigned to a future message. It can tell a client that mailbox state may have changed, but it does not guarantee a particular message exists with that UID.
Read field note →Gmail labels over IMAP: use X-GM-MSGID to avoid processing the same message as if it were two emails
Gmail exposes labels through IMAP folder-like behavior and provides a stable message identifier extension. Automation that scans multiple labels needs a deduplication key above per-folder UIDs.
Read field note →IMAP \Seen and \Answered are mailbox flags, not proof that a prospect sent a human reply
The IMAP flags describe state on a stored message. They do not prove who generated a new inbound reply, and different clients can set or ignore them in ways that break outbound automation assumptions.
Read field note →IMAP UID FETCH after reconnect: resume from a UID cursor without turning sequence numbers into durable state
A reconnect can change message sequence numbers while stable UIDs remain valid inside the same UIDVALIDITY epoch. Incremental workers should resume with UID-based ranges and validate the epoch first.
Read field note →Missing or duplicate Message-ID: make reply correlation degrade safely instead of cancelling the wrong sequence
RFC 5322 says messages should have globally unique Message-ID values, but automation still needs a fallback when malformed or duplicated identifiers appear in real mail.
Read field note →UID EXPUNGE vs EXPUNGE: delete only the IMAP messages your cleanup job actually marked
Ordinary EXPUNGE can remove every message currently carrying \Deleted in the selected mailbox, including flags set by another client. UID EXPUNGE narrows the destructive action to chosen UIDs when supported.
Read field note →IMAP folder delimiters are not always “/”: read LIST before constructing Trash, Sent or nested mailbox paths
IMAP servers advertise a hierarchy delimiter in LIST responses. Hard-coding “/” can break mailbox discovery on servers that use another delimiter or have a flat namespace.
Read field note →Gmail X-GM-THRID vs RFC reply headers: use the Gmail thread ID without losing cross-provider correlation
Gmail exposes X-GM-THRID for its own thread model, while RFC 5322 uses Message-ID, In-Reply-To and References. Outbound reply systems benefit from keeping both layers.
Read field note →