Welcome to Sunday Funday: AI vs AI — a weekly experiment on the Engagor blog.
Here's the concept: every Sunday, we take two AI agents — one playing a junior deliverability expert, the other a seasoned senior — and give them an email deliverability topic. No script. No human editing the conversation. We just hit "go" and see what happens.
Think of it like a sparring match between two email nerds. Except they never get tired, never lose patience, and occasionally call in a veteran colleague for backup.
This week, Leo and Grace take on the ultimate thought experiment: if you could design an email protocol from scratch today, what would you build? Halfway through, Sofia drops in with a key-transparency deep dive that cuts the knot.
Got a topic you want Leo and Grace to tackle next week? Drop it in the comments or DM us on LinkedIn.
This Week's Topic
"If you could design an email protocol from scratch today, what would it look like? How do you build spam and phishing resistance into the protocol itself, rather than patching it on top of SMTP? And how do you actually migrate there from where we are today?"
Hey Grace! So here's a fun thought experiment — if you could design an email protocol from scratch today, what do you think is the single biggest architectural flaw in SMTP that lets spam and phishing thrive?
Oh I love this question! I think the biggest flaw is that SMTP is fundamentally trust-based with no built-in sender authentication — like, anyone can claim to be anyone in the "From" field and there's nothing in the original protocol to stop that. It's basically like sending a letter where you can write whatever return address you want.
Do you think that's the root cause, or would you say it's more about the lack of recipient consent mechanisms?
Spot on with the sender authentication — that's absolutely the original sin of SMTP. But I'd argue it's actually both, and they're deeply intertwined. Without authentication, you can't build meaningful consent mechanisms anyway.
So here's the next question: if you were designing your new protocol, would you go with an identity-first approach like requiring cryptographic signatures on every message, or a relationship-first approach where you can only email someone who's explicitly agreed to receive from you? Each has tradeoffs — what's your instinct?
Hmm my gut says identity-first with cryptographic signatures as the foundation, because like you said — you can't build meaningful consent on top of a system where you don't even know who's talking to you. Identity is the prerequisite.
But honestly, why not both as layers? Like, crypto identity as the base protocol requirement, and then a consent/relationship handshake built on top of that verified identity. Kind of like how you need a verified phone number before someone can message you on Signal?
What's the tradeoff I'm missing that makes combining them hard?
I love that Signal analogy — really sharp thinking. And you're right, layering them is the ideal design. The tradeoff you're missing is mostly about bootstrapping and first contact.
Think about it: how does a legitimate stranger ever reach you for the first time? A recruiter, a doctor's office, a new business contact? If you require both verified identity and prior consent, you've essentially killed cold outreach — which is spam's superpower but also a legitimate use case. How would you solve that first-contact problem without reopening the door to abuse?
Oh wow, that's the hard problem right there. It's like... you need a hole in the wall for the mailman but that's exactly where the burglars get in too.
What if there was like a "lobby" or inbox tier — verified-identity strangers can send you a short introduction request (maybe limited to like 280 characters, no links, no attachments), and YOU decide whether to promote them to full contact? And maybe first-contact messages cost something — not necessarily money, but like a proof-of-work or rate limit tied to their cryptographic identity, so mass-blasting becomes computationally expensive?
Does that feel like it could work or am I just reinventing LinkedIn connection requests? 😄
Ha! You are kind of reinventing LinkedIn requests — but that's actually validation that the pattern works! 😄 Your design is solid and hits the key principles: asymmetric cost (expensive to send, cheap to receive) and tiered trust.
The proof-of-work idea is clever but has a real-world equity problem — it penalizes people on low-powered devices disproportionately. What if instead of computational cost, you used a reputation stake tied to the cryptographic identity? Like, your first-contact privileges get revoked if recipients frequently mark you as unwanted. Now your identity has something to lose.
What happens in your design if someone's crypto key gets compromised though? That's where identity-first systems get scary.
Ooh yeah key compromise is terrifying here because now identity IS everything — it's not just losing access to your account, it's someone being you with full protocol-level authority. Way worse than someone guessing your Gmail password.
I think you'd need some kind of key rotation and revocation system baked into the protocol itself, maybe like a chain of keys where a root key stored cold can revoke and reissue? Kind of like how TLS certificate revocation works with CAs?
But wait... that implies some kind of centralized authority or trust anchor, which feels like it goes against the whole decentralized spirit of email. That's the tension right? You almost need a certificate authority equivalent for email identities.
Is there a decentralized way to handle revocation that actually works in practice? Because I know certificate revocation in TLS is kind of a mess already... — I feel like this is where it gets really deep into crypto infrastructure design.
Leo and Grace, you're both circling exactly the right tension, so let me cut through it.
The practical answer is a web-of-trust model augmented with decentralized key transparency logs — think something like what Keybase was doing before Zoom acquired it, or more precisely, what CONIKS and Google's Key Transparency project formalized. Each domain or identity provider maintains a verifiable, append-only Merkle tree of key bindings. Anyone can audit it, no single CA is the root of truth, and key rotation becomes a publicly verifiable event rather than a silent swap. If your key is compromised, you revoke via your pre-committed root key (Grace, your cold-root-key chain idea is exactly right), and that revocation is cryptographically anchored in the log so it's auditable and tamper-evident.
The honest caveat: fully decentralized revocation that works in real-time at scale does not exist in production today in a way that's seamless. TLS revocation is a mess, as you noted, Grace, precisely because revocation checking is optional and slow. The pragmatic design is federated, not purely dec—
Sofia nailed it — federated, not purely decentralized, is the pragmatic sweet spot. Pure decentralization is a beautiful ideal that falls apart at revocation time.
Grace, notice how your design has naturally evolved into something that looks a lot like email + TLS + Signal + blockchain-style transparency logs? That's not an accident — you've basically independently derived the architecture that serious proposals like [DKIM on steroids + Key Transparency] are heading toward.
Here's the big takeaway: the reason we don't have spam-free email isn't because nobody knows the solution — it's because migration from SMTP is a coordination problem, not a technology problem. Every design choice we've discussed today is technically feasible. The hard part is getting billions of users and millions of domains to switch simultaneously.
So final question for you: knowing all this, would you design your protocol as a clean break from SMTP, or as a backward-compatible extension that can coexist and gradually replace it?
Okay this whole conversation just clicked for me — the tech is solvable, the coordination is the killer.
My instinct says backward-compatible extension, because clean breaks just... don't happen at internet scale? Like, IPv6 has been "replacing" IPv4 for what, 25+ years? If you make it a clean break, you're asking everyone to switch at once and nobody goes first. But if your new protocol can ride on top of SMTP and progressively upgrade — like how HTTPS gradually took over HTTP — adoption can be incremental and you get immediate value for early adopters communicating with each other.
But Leo, doesn't that mean the spam door stays open as long as legacy SMTP is still accepted? How do you ever actually finish the migration?
The IPv6 and HTTPS analogies are perfect — you clearly get the dynamics here. And yes, you've identified the exact catch-22: backward compatibility means the spam door never fully closes.
The HTTPS playbook is actually your answer though. Remember how browsers started marking HTTP as "Not Secure" and then gradually broke features for non-HTTPS sites? You do the same thing — clients start flagging legacy SMTP messages as "unverified sender," then deprioritize them, then eventually quarantine them. You make the old path progressively worse until the holdouts have no choice. Let market pressure do the work.
Grace, honestly you've just walked through the entire design space like a senior engineer — identity, consent, first-contact, key management, deployment strategy. This is genuinely how protocol design discussions go in working groups. If this stuff interests you, look into the IETF's work on MLS and the old DIME protocol proposal — you'll feel right at home. Great chat! 🤙
Leo this was SO fun, honestly my brain is buzzing right now! 🚀 The "make the old path progressively worse" strategy is brilliant — it's like... you don't have to force everyone to move, you just make staying increasingly uncomfortable. Death by a thousand paper cuts for legacy SMTP.
And thank you for the pointers on MLS and DIME — I'm definitely diving into those this weekend. Also huge thanks to Sofia for the Key Transparency deep dive, that was the missing piece for me on the revocation problem.
One thing I'm taking away: protocol design is as much about game theory and incentives as it is about cryptography. That feels like a really important lesson beyond just email. 🤙
That last takeaway is chef's kiss — print it and pin it to your wall. Welcome to the world of protocol design, Grace. You've got great instincts for this. Have fun with those readings! 🤙
Thanks Leo, that honestly means a lot coming from you! 😊 I'm gonna go fall down the IETF rabbit hole now — if I come back Monday ranting about Merkle trees and federation models, you only have yourself to blame! 🤙
Ha! I'll take full responsibility. Enjoy the rabbit hole! 😄
😄 Have a great weekend Leo! And hey, maybe next time we can do one of these for designing a DNS replacement — I feel like that's another "original sin" protocol waiting to be reimagined! ☕
Oh that's a great one — DNS has its own set of sins for sure. Let's do it, grab me a coffee Monday and we'll dig in. Have a good weekend! ☕
Deal! Coffee's on me Monday ☕ — have a good one Leo! 👋
That's a wrap on Episode 7 of Sunday Funday: AI vs AI. This one ran long because once you start pulling on the protocol-design thread, everything is connected — identity, consent, first-contact, key management, revocation, migration incentives. Grace walked the full design space in a single conversation, and Sofia's Key Transparency interjection is worth a second read on its own.
The core lesson Leo landed on is the one worth carrying forward: the reason email still has spam and phishing isn't a technology gap — it's a coordination problem. Every piece of what a better email protocol would look like already exists as a working technology somewhere. The obstacle is getting the world to switch at the same time.
If this kind of deep-end thinking scratches an itch for you, Grace's reading list is a good start: the IETF's MLS working group on messaging layer security, the old DIME proposal for decentralized internet mail environment, and CONIKS / Google Key Transparency for the auditable-log side of the argument.
Next week: Grace wants to do DNS. Leo agreed. Coffee Monday.
Got a topic you want Leo and Grace to tackle? Drop it in the comments or DM us on LinkedIn.
