기존 기술을 조립해 만드는 차세대 이메일

Let's design the successor to email on top of HTTP, fixing the design flaws SMTP has been dragging along for 40 years. Piece by piece. The goal is not to replace the current mail system, heaven forbid!, but to learn, have fun and discover current technologies to swap out every element: sending, receiving, gateway, keys, and so on. The system will never talk to Gmail or any classic email provider: it only talks to itself. The only thing we are going to keep is the shape of the addresses, user@domain . Everything else gets reinvented. Since it is a mail system over HTTP, a good name for the protocol would be HMTP: Hypertext Mail Transfer Protocol (the S for Simple in SMTP gives up its seat to the H for HTTP). Now it's time to prepare the tech stack: HTTP, TLS, WebFinger, ActivityPub, Webmention, Ed25519, HPKE, sigchains, etc. The bill of materials This design doesn't invent a single technology: everything already exists. Problem Existing technology Who uses it today Transport and status codes HTTP The whole web Transport encryption TLS + Let's Encrypt The whole web User discovery WebFinger (RFC 7033) Mastodon and the Fediverse Message delivery POST to an inbox ActivityPub Sender verification at the source The Webmention and DKIM pattern IndieWeb, all of email Signatures Ed25519 SSH, Signal Content encryption HPKE (RFC 9180) MLS, TLS ECH Identity that survives key rotation Sigchains ATProto (Bluesky), Keybase Reading and synchronization JMAP (RFC 8620) Fastmail Push notifications SSE / WebPush Every browser First-contact consent Message requests Signal, Instagram Attachments by reference with hashes Content addressing Git, IPFS, Matrix Every piece we are going to use is standardized, deployed and battle-tested at scale by millions of people; the only new thing is the assembly. Choosing HTTP is not just pragmatism. It solves, right out of the gate, several things any new protocol would have to build at some point: TLS, virtual hosting and SNI : for free. Status codes : the catalog a mail protocol needs already exists in HTTP. 202 Accepted (queued for delivery), 429 Too Many Requests + Retry-After (rate control), 404 / 410 (mailbox unknown/gone), 3xx (mailbox moved), 413 (too large). Even paid anti-spam has had a code reserved since 1997: 402 Payment Required . Existing infrastructure : proxies, load balancers, Nginx, libraries in every language. The protocol stops being a new server and becomes a convention over HTTP , like Webmention or Micropub. Let's move to the next level: how do we discover a user, verify their identity, deliver the message, sign it and encrypt it, all over HTTP? 1. Discovery and delegation (a better MX) Delegation is solved with a static document: GET https://example.com/.well-known/hmtp/ana { "inbox": "https://mail.migadu.example/hmtp/inbox/ana", "keys": { ... }, "devices": [ ... ] } The inbox can live on another host: that is the MX record, but without touching DNS. A static blog on GitHub Pages can delegate its mail to a provider by serving a JSON file. And it allows something MX never did: per-user delegation (each mailbox of a domain on a different provider). We wouldn't even need to invent the route: WebFinger (RFC 7033) does exactly this, and Mastodon has already proven it scales. 2. Identity that survives key rotation Identity cannot be a key (they get lost, they expire); it has to be something that keys back . A proposal with two anchors: Cryptographic continuity : the discovery document publishes the current key and a chain of rotations, where each new key is signed by the previous one. Anyone who knew you with key N can verify key N+1 without trusting anybody. It's a sigchain, what ATProto does with DIDs or what Keybase used to do. Domain control as a fallback : if you lose the key without a signed rotation (your laptop gets stolen), the domain declares a new key without a chain, with a mandatory announcement period (say 30 days) during which the servers that knew you show the warning "identity re-anchored by domain, not by signature". However, domain-anchored identity has its own Achilles heel: a domain is not owned, it is rented. If you stop paying, it expires and someone registers it, the new owner publishes their keys in your .well-known and from that moment on they receive your mail and sign as you. Nobody can tell the legitimate heir from the squatter. It's the problem ATProto tries to solve by separating identity from the domain with DIDs, at the price of another piece of infrastructure. We know it's a real problem with a known solution. Now let's move on. 3. Delivery with a queue (store-and-forward) Delivery is a POST to the recipient's inbox: POST /hmtp/inbox/ana HTTP/1.1 Host: mail.migadu.example Content-Type: application/hmtp+json The key is not the request, it's who makes it. Your client doesn't deliver directly to the recipient, but to your own server (an authenticated POST to your outbox), and it is your server that queues, retries with exponential backoff and honors Retry-After . It's admitting that SMTP's MUA/MSA/MTA separation was right. One of email's quiet strokes of genius is that if the destination server is down, your server retries for days and you forget about it. But let's add an improvement SMTP never had. Every message carries an ID that is the hash of its content, so retries are idempotent. The receiving server deduplicates by ID and the classic "duplicate email because the ACK failed" disappears by construction. The full cycle of a delivery, with the destination node down on the first attempt: sequenceDiagram autonumber participant Ana as Ana's client participant SA as Ana's server participant SB as Bob's server Ana->>SA: POST /outbox (signed message) SA-->>Ana: 202 queued SA->>SB: GET /.well-known/hmtp/bob SB-->>SA: Bob's inbox and keys SA->>SB: POST /hmtp/inbox/bob (envelope + sealed body) Note over SB: down: no response Note over SA: queue: retries with exponential backoff SA->>SB: POST /hmtp/inbox/bob (retry, same id) SB->>SA: GET /.well-known/hmtp/ana SA-->>SB: Ana's signing key Note over SB: signature verified, deduplicated by id SB-->>SA: 201 delivered Notice that the diagram contains the entire protocol: the two GETs to .well-known are discovery and verification, the POST is the delivery, and the queue lives where it should, on the sender's server. 4. Signing and encrypting with the keys we already have The message is a signed object, not loose text: { "id": "sha256:9f2c...", "from": "ana@example.com", "to": ["bruno@example.org"], "date": "2026-07-26T10:00:00Z", "in_reply_to": "sha256:11ab...", "subject": "Re: that idea", "body": { "type": "text/markdown", "content": "<encrypted>" }, "signature": "..." } This buys us a lot of things: Authenticity at rest : stored mail carries its cryptographic proof. A forward keeps the original signature. Forging the sender becomes impossible even through chains of forwards. Sender verification without DKIM : the receiving server GETs the .well-known of the from domain and checks that the key signs. It's the same move as Webmention verification. The proof is fetched at the source. E2E : the discovery document publishes encryption keys (X25519); the body is sealed with HPKE. The envelope (from, to, id, date) stays visible for routing and filtering; the content, only for the recipient. Threads : in_reply_to and references by content hash. Conversations reconstructed without heuristics. Attachments : outside the message. An attachment is {hash, url, size} pointing to the sender's server; the receiver downloads it on demand and their server can mirror it. No more base64 bloating mailboxes. 5. Layered anti-spam Like in any system, this is a complex problem that needs several layers of defense. With HMTP we could start with three: Identity cost : signing as ana@example.com requires serving the key document at example.com . Identity is anchored to a domain, and domains cost money. It's the sybil cost that self-signed identities don't have. However, a doma