Threading that survives the reply
Threading is the difference between a conversation and a pile of messages. It is decided by two headers, and an agent that ignores them produces mail that technically arrives and practically cannot be followed.
Two headers, and everything else follows
Every message has a Message-ID. A reply carries the id of what it answers in In-Reply-To, and the whole chain in References. Gmail, Apple Mail and Outlook group on those. The subject line is a hint for humans, not the join key.
# stays in the conversation: headers are filled for you
reply_thread { threadId, html: "<p>Shipped this morning.</p>" }
# opens a NEW conversation, even with the same subject
send_from_inbox { inboxId, to: "[email protected]", subject: "Re: order 4182", html: "..." }Both calls deliver. Only the first one continues the conversation, on the recipient's side as well as in the inbox.
Inbound gets threaded on the way in
When a message arrives, we read its references and attach it to an existing conversation when there is one. Mail that answers something you sent lands next to it, with the attachments of both directions in the same place. What comes in with no reference at all opens a new thread, which is the honest outcome: guessing by subject merges unrelated conversations that happen to share a word.
Folders are computed, not filed
The ten folders are queries over thread flags, message direction and the result of the sender checks. Nothing has to be moved, and nothing can be in the wrong place: an unauthenticated message is in that folder because SPF, DKIM or DMARC said so, not because a rule ran once and left a label behind.
For an agent this means the folder is a filter it can trust when deciding what to read first, without maintaining state of its own.
Questions
What actually keeps a reply in the thread?
The In-Reply-To and References headers, carrying the Message-ID of what you are answering. Mail clients group on those, not on the subject. Sending fills them for you when you reply to a thread, which is the whole reason reply_thread exists next to a plain send.
What happens if I reply with a new send instead?
It arrives, and it lands as a separate conversation. The recipient sees two threads about one topic, and every later reply forks between them. Nothing errors, which is exactly why this is worth knowing before it happens.
Are folders labels I have to set?
No. They are views over the state of the thread and the outcome of the sender authentication checks: inbox, starred, sent, drafts, important, scheduled, all mail, spam, unauthenticated and trash. An agent never has to file anything, and a thread cannot end up in two places that disagree.
Keep reading
One inbox per agent
Why an agent needs an address of its own, where it should live, and what a shared domain costs you in practice.
Threading that survives the reply
How a reply stays in the same conversation on the recipient's side, and why folders are views rather than labels to maintain.
Inbound webhooks, signed
Being told a mail arrived instead of polling for it, and verifying the signature before you trust the payload.
Allow and block rules
Deciding who may write to an agent, and what happens to mail that fails SPF, DKIM or DMARC.
