IMAP \Seen and \Answered are mailbox flags, not proof that a prospect sent a human reply

What the standard or provider is actually evaluating

RFC 9051 defines \Seen as “message has been read” and \Answered as “message has been answered.” These flags live on mailbox messages and can be changed by clients; they are not a standardized CRM event indicating that a particular prospect authored a reply.

IMAP flags describe mailbox state, not the business meaning of a conversation. `\Seen` means a message has been marked as seen; that can happen through a human client, a preview pane, a server rule, or your own code if it fetches content without PEEK semantics. `\Answered` indicates the message has been answered in the mailbox’s IMAP state, but it does not by itself prove that a particular lead sent a new human reply to a particular outbound sequence. A reply detector should start from new inbound messages and their headers, sender/recipient identity, and conversation references rather than inferring human intent from flags on the original outbound message.

The shortcut that breaks the diagnosis

The word “Answered” sounds semantic enough to drive sequence state, but the flag can represent a user-agent action unrelated to your outbound system’s correlation logic and may not be set consistently across clients.

A tempting shortcut is to scan Sent or Inbox for `\Answered` and cancel follow-ups whenever it appears. That can misfire when an operator answers an unrelated thread, a client sets flags differently, or automation touches the mailbox. Likewise, using `\Seen` as evidence that a prospect read an email confuses your own mailbox state with recipient behavior; the recipient’s read state is not exposed to the sender through IMAP. Keep flags useful for synchronization and UI state, but do not elevate them into deliverability or engagement facts they were never designed to represent.

Build a control case before editing production

Create controlled messages, read them from two clients, send replies, and observe which flags each client changes. Compare those results with the actual inbound Message-ID, In-Reply-To, sender address, and your own conversation mapping.

Build a fixture with three messages: an outbound message marked Seen, the same message marked Answered by a test client, and a genuine inbound reply carrying From plus In-Reply-To/References. Your system should cancel the follow-up only for the inbound reply path that matches the lead/conversation rules, not simply because flags changed. Fetch flags and headers separately in logs so the test demonstrates which evidence drove the decision. Also verify that reading message headers through the worker does not inadvertently set `\Seen`, because your own inspection should not mutate the signal you are testing.

Fix the state that the evidence names

Base reply detection on new inbound messages plus deterministic correlation and store a processed-event ID. Flags can help UI or synchronization, but the campaign state machine should not depend on them as its only evidence.

Store IMAP flags as synchronization metadata and store `reply_detected` as a separate derived business event with the evidence that justified it. That event can reference provider message ID, RFC Message-ID, sender identity, matched lead, and the outbound message it replies to. If the match is ambiguous, route it for review or hold future sends briefly rather than declaring a reply from a single flag. This separation makes the pipeline portable across clients and providers whose flag behavior differs and makes post-incident audits much clearer when someone asks why a sequence stopped.

An operator-sized scenario

A sales rep can manually mark a sent message as answered without any recipient reply, or a provider can receive a reply while leaving the original message’s flag unchanged. Both outcomes defeat a flag-only rule.

Human-response classification should also consider direction. A reply detector can require that the new message’s sender is external relative to the managed mailbox and that its recipient/conversation context maps back to a stored outbound message. This avoids treating the operator’s own sent reply, a copied internal address, or a server-generated flag change as prospect engagement. Keep confidence levels if the evidence is incomplete: a message with strong References but an unfamiliar sender alias may be “matched conversation, sender needs resolution,” while an OOO can be “automatic matched conversation.” Those states give the scheduler a safe pause option without falsely recording a positive human reply. Flags remain useful to avoid reprocessing or to preserve mailbox UX, but they should never become the sole business trigger.

Fields that make the decision auditable

Keep inbound UID, message identifiers, normalized sender, correlation result, Auto-Submitted value, and the application event that cancelled the sequence. Flags can be recorded as secondary context.

Do not turn this edge case into a universal rule

Do not remove flags from the mailbox merely to make automation simpler. Other clients may rely on them; isolate your state in the application rather than commandeering shared mailbox semantics.

Field checklist

• Capture the raw evidence for IMAP Seen Answered flags human reply detection before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using imap-rfc, message-rfc rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for IMAP \Seen and \Answered are mailbox flags, not proof that a prospect sent a human reply and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.