> ## Content Index > Fetch the complete content index at: https://www.ostering.com/llms.txt > Use this file to discover other available public pages before exploring further. # Elevation of Email Flow Launch - URL: https://www.ostering.com/elevation-of-email-flow/ - Published: 2026-11-05T20:55:00.000Z - Updated: 2026-11-05T20:32:21.899Z - Description: A threat modeling card game for email infrastructure: 125 cards across nine layers of the email stack, played against your own mail flow. - Author: Brett Crawley - Tags: DKIM, Elevation of Privilege, Email Security, Games, SMTP, Threat Modeling ## Threat modeling the machinery that delivers email **TL;DR:** Elevation of Email Flow is a threat modeling card game for email infrastructure, in the tradition of Elevation of Privilege. 125 threat cards: 117 in nine suits, one per layer of the email stack, plus eight Trumps for the structural hazards of email itself. You play it against a diagram of your own mail flow and walk away with a findings log. Coming soon. If you’d like a deck when it’s published, send me a message on LinkedIn. Knowing there’s demand helps a publisher decide which games to prioritise. Email carries credentials, payment instructions, legal notices and password resets. It is the most impersonated channel in enterprise security. Yet the machinery that delivers it has no threat modeling taxonomy of its own. A while back I tried some automated tools for threat modeling email-related projects and found that they didn’t include any email components. The threat modeling games don’t cover it either. So threat modeling an email product comes down to what the team already knows about the threats, and that is a risk in itself. I decided to fill that gap and give it a structured method. ### Why not just use STRIDE? At first glance STRIDE covers it: spoofing, tampering, denial of service. However, STRIDE was built for other systems, and it surfaces the obvious. It doesn't surface: - a gateway that delivers when its sandbox times out - a verdict header an outside sender can forge - a DKIM signature replayed to two million strangers - two parsers that read the same bytes and see different messages Those are the failures that matter in email, and nobody on the design team has a card that names them. The people who build mail platforms are skilled at what they build. What they rarely have is a structured way of asking what can go wrong in this component, at this trust boundary, in this order. ### Nine suits, one per layer Delivery Pipeline, Authentication Protocols, Client Protocols, SMTP, MIME and S/MIME, DNS Layer, Content Scanners, the Human-Facing Layer, and Operations and Storage. Every card states a threat as a property of a component or a design decision, then gives three **mitigation prompts**: plain questions the design should be able to answer. Each suit carries one habit of thought, for example: - an authentication pass proves a domain, not good intent - SMTP believes whatever a peer asserts - whoever controls a DNS answer controls the mail - a scanner is a probabilistic control an attacker can study The eight **Trumps** go a step higher, with cards such as *Check Once, Use Later* and *Authentication Is Not Trust*. Each one explains dozens of individual findings and points to an architectural change rather than a patch each. ![Five of the 127 Elevation of Email Flow cards: EM-DP-A Ingress Bypass, EM-AU-Q DKIM Replay, EM-SM-J SMTP Smuggling, EM-CS-K Scanner Prompt Injection and the Trump EM-T8, Envelope and Header Duality. Each card has its threat, an illustration and three mitigation prompts.](https://www.ostering.com/media/posts/86/eoef-card-fan-1600x9002x.png =3200x1800 "Five of the 127 cards: one threat each from the delivery pipeline, authentication, SMTP and the content scanners, and one of the eight Trumps, the hazards of email itself.") ### How it plays Put a diagram of your own mail flow on the table: the hops, the scanners, the mailbox store, the clients. Choose the suits that match the design, shuffle them with the Trumps and deal. Play is trick-taking. The leader plays a card, reads the threat aloud and makes a **claim**: which element it lands on, and how. The table tests the claim with the card's prompts. - If the design can't answer a prompt, that is a **finding**. The Scribe logs it and the player scores. - If it can, the Scribe logs **no exposure** with the reason, which is worth having too. Everyone else follows suit against a different element. Trumps can't be led until one has been played, so they arrive late, when the log is already filling. A Trump claim must connect two or more elements or findings to one structural cause, and scores double. The real prize isn't the points. It is the findings log: threats against your own design, each tied to an element, ready for the backlog. ### See it played first There is a worked example against **Heronpost**, a fictional mail platform. It plays all 125 cards and yields 115 findings, so a first-time group can see what a good claim looks like before making their own. **Note to email platform teams:** you don't need a security background. You need a working picture of how mail moves through your system. The cards carry the questions. **Note to security architects:** run two or three suits plus the Trumps in a 60 to 90 minute session, and treat the full deck as a campaign. ### What's in the box A poker-size deck of 126 cards (125 threats and a quick-reference card) in a tuck box, with a rule booklet. The deck is themed on the post: airmail chevrons, a postmark with suit and rank, typewriter text, an X-ray panel tagged "Opened for inspection", and a sealed envelope stamped THREAT on the back. The game follows the trick-taking format popularised by Elevation of Privilege, created by Adam Shostack at Microsoft and released under CC BY 3.0. It reuses none of that game's card text or artwork. Coming soon. If you’d like a deck when it’s published, send me a message on LinkedIn. Knowing there’s demand helps a publisher decide which games to prioritise. Happy threat modeling!