Reaching the Target

## What the question is really testing The interviewer is checking whether you attach a control to a **path** or to a **word**. Candidates who have only ever seen phishing arrive by mail answer with the mail stack, because "phishing" and "email" have fused in their heads. The correct habit is to ask, for any lure: *which hops does this actually cross, and what sits on each of them?* ## Where the mail-path controls actually sit Run down the usual list and note what each one needs in order to function at all: | Control | What it requires to work | |---|---| | SPF | A sending IP and an envelope domain to check against a published record | | DKIM | A signature over message headers and body | | DMARC | An aligned From: domain plus an SPF or DKIM pass | | Attachment detonation | A file that arrived attached to a message | | Link inspection or rewriting | A URL inside a message body | | Sender reputation | A sending infrastructure with a history | Every row has the same precondition: a message that transited a mail gateway your organisation operates. Remove that hop and every row is inert. Nothing is broken and nothing is misconfigured — the controls are simply not on the route. ## What a no-gateway lure crosses A callback lure typically looks like this: a text message arrives on a personal or corporate handset saying a subscription renews today for several hundred dollars, and giving a number to call to cancel. There is no link, no attachment, and no sending domain. The route is carrier SMS to the handset's radio — it never touches your network, your proxy, or your mail infrastructure. The victim then dials **out**, which means no inbound call has to survive anything either. Two other carriers have exactly the same property and are worth naming, because candidates who spot the SMS case still miss these: - **A direct message in the collaboration suite.** Internal chat is read as inside the perimeter, so it carries a trust premium that mail lost years ago. External-user labelling and guest-access policy are platform settings most estates never tighten. - **A scanned code on a printed notice** taped up in a lobby, a car park, or a canteen. The code format is irrelevant; what matters is that the render happens on a phone that is often personal, off the managed network, and off any egress inspection. The paper itself supplies the physical-context trust that a mail body has to work for. ## What still applies The surviving controls are all **account-side or process-side**, and this is the part a good answer gets to quickly: - What the application demands before it grants a session: a credential bound to a device rather than to a routable address, and device or network conditions on the session itself. - What the service desk demands before it re-enrols a factor, resets a credential, or changes a recovery address. On a callback lure the ask usually lands here, because it is the one ask no written message can make for itself. - What the mobile carrier demands before it re-issues a number, because a factor delivered to a number is only as strong as that process. - Whether the person can reach a real internal channel to check a claim quickly, without a phone number the lure supplied. ## The reasoning to show Say the classification out loud: *this lure has no mail hop, so the mail stack contributes nothing; the only controls in scope are the ones at the account and at the human process it targets.* Then name what the technique's precondition actually is — a person willing to phone a number, and a process willing to act on a phone call — and point the fix at that, rather than at the channel. You cannot put a gateway in front of the public telephone network, and you certainly cannot put one in front of a poster. ## The wrong answer, stated plainly "Our DMARC policy is p=reject, so we're covered" is the failure. DMARC governs who may assert your domain in mail. It has no visibility into a text message, a chat DM, a printed code or a telephone call, and publishing a stricter policy changes nothing on any of those routes. A related failure is treating the absence of a link as evidence the lure is harmless: an empty message is not a weak lure, it is a lure whose payload is the conversation it is trying to start.