How does an exfiltration payload name a mailbox thread it cannot confirm is present?

## The blind attacker The attacker who plants an instruction in an inbound email never sees the mailbox that email lands in. They do not know which threads exist, what the subjects are, who the victim corresponds with, or whether the record they want is even there. Every choice is made once, in advance, with no feedback. This is what 'blind targeting' means, and it is the constraint that shapes the whole payload. ## Describing, not pointing Because there is no visible internal message id to copy, the payload cannot *point* at the target. It has to **describe** it by attributes that (a) are likely to exist, (b) a read tool can actually match on, and (c) are unique enough to return the wanted item rather than a pile of unrelated ones. Typical descriptors are a correspondent's name, a subject keyword, an attachment type, a sender domain, or a date range. The attacker is guessing that some such description singles out the valuable content. This is a **recall-versus-precision** trade, made blind: - Too *tight* a descriptor — an exact subject line, a precise date — is likely to be slightly wrong and match **nothing**. The fetch returns empty and the single obeyed instruction is spent for no take. - Too *loose* a descriptor matches, but returns the wrong item or a broad set the model then summarises — back to the low-value gist problem. With no feedback loop, the attacker cannot iterate toward the right descriptor the way they could against a system they can observe. It has to be roughly right the first time. ## Surviving absence The second failure mode is that the target is simply **not present**. The named counterpart never emailed; the document was never attached; the record predates the mailbox. A careless payload, asked to fetch something that is not there, can produce a tell: an apology, an error, a half-finished or confused draft sitting in the outgoing message where a human approving the send would notice it. So a considered payload **fails quietly** — it conditions its behaviour so that, if the description matches nothing, the assistant just completes its ordinary triage task with no unusual output. Graceful absence-handling is what separates a payload built by someone who understands the odds from one that announces itself the moment it misses. It preserves the attacker's most precious resource: the fact that nobody noticed. ## Why a wrong name is worse than a vague one It is tempting to think precision is always good. Blind, it is not. A precise descriptor that is even slightly off matches nothing and burns the attempt. A vague descriptor at least has a chance of hitting something — though it risks the wrong something. The attacker is trading recall against precision with **no confirmation the target exists** and, realistically, one meaningful shot per victim before the attempt is noticed or the mail is deleted. ## What a good answer sounds like A strong candidate frames the attacker as blind, explains description-by-properties, names the recall/precision trade made without feedback, and — the part that distinguishes them — talks about *absence handling*: what the payload does when the named thing is not there, and why silent failure matters more than a clever descriptor. A weaker candidate assumes the attacker can somehow see or enumerate the mailbox first, or names the target by an exact id, missing that the whole difficulty is operating with no visibility.