How does a hijacked email reply chain make a lure indistinguishable from a real thread?

## The inversion A constructed lure has to invent context: a plausible sender, a plausible subject, a plausible reason for writing. Every invented element is a place where the operator can be wrong. Thread hijacking removes the invention. The operator obtains access to a mailbox belonging to somebody the target already talks to — a managed-service provider is the classic case, because one compromised mailbox in a shared-tenancy provider yields live conversations with dozens of that provider's customers — and then answers a conversation that already exists. Everything that would normally have to be faked is now simply true. The correspondent is real. The subject line is one the recipient wrote or agreed to. The history quoted below the reply is the actual history, because it was copied from the actual thread. And the message really did originate from the mailbox it claims, because the operator is sitting in that mailbox. ## What makes the client file it as a continuation Mail threading does not run on the `Re:` prefix in the subject, which is only a convention. It runs on message identifiers. Every message carries a `Message-ID`. A reply carries `In-Reply-To` holding the identifier of the message it answers, and `References` holding the chain of identifiers back through the conversation. A client that receives a message whose `References` chain overlaps a conversation it already holds will thread it under that conversation. An operator replying from inside the real mailbox does not have to forge any of this: pressing reply produces it. The result lands in the recipient's mail client in the visual position the recipient expects — nested under the thread they themselves started eight messages ago, immediately below their own last message. That placement is doing more persuasive work than any sentence in the body. ## The one divergence, and why it exists The operator usually needs replies to come to them rather than to the mailbox owner, who is still using the account and would notice a customer answering a message they never sent. So the message carries a `Reply-To` header pointing somewhere else: a domain a single character from the genuine one — a dropped hyphen, a doubled letter, or a glyph pair such as `rn` standing in for `m`. That divergence is the whole tell, and it is weak by design. Most mail clients render the friendly display name and collapse the address behind it, and almost all mobile clients do. `Reply-To` in particular is rarely surfaced at all until the recipient presses reply, at which point the address sits in a field they are not reading. A recipient checking 'is this from the right person' looks at the `From` line, which is genuinely correct. ## The rung below If the operator can only read the mailbox and cannot send from it, the same shape is available at a lower quality. They register the lookalike domain, put it in the `From`, re-create the subject line, and paste the copied history underneath. This is close, but it now depends on fabricated elements: the domain is wrong rather than merely the reply address, the threading identifiers will not match anything the recipient's client holds so the reply arrives as a new conversation rather than nested in the old one, and the pasted history can drift in formatting. That is a materially cheaper and materially weaker construction, and the distinction between the two rungs is what interviewers are usually probing. ## What this changes about reasoning Two direction errors are worth stating explicitly, because both are common answers. The first is treating the genuine origin as proof of a genuine author. A message sent from a real mailbox by somebody who holds the credentials to that mailbox really was sent by that account. It was not sent by that person. Anything that asks 'did this come from where it claims' will answer yes, correctly, and answer a question nobody needed asked. The second is treating the quoted history as something to scrutinise. Candidates often say they would check whether the earlier messages look real. They are real. They are the recipient's own words. Reading harder is not a strategy against a message where every element except one reply address is authentic. The useful conclusion is that thread hijacking moves the problem out of the message entirely. The message is not distinguishable at reading distance; what remains distinguishable is what the request is allowed to accomplish once believed.