Constructing Modern Email from Existing Components

By Andros Fenollosa

The objective here isn't to destroy replace the current email ecosystem—heaven forbid!—but rather to experiment, learn, and identify modern technologies that can substitute every legacy component: from transmission and reception to gateways and cryptographic keys.

This conceptual successor to email is built entirely on top of HTTP, aiming to rectify the architectural flaws that SMTP has carried for four decades. This system is a closed loop; it will not communicate with Gmail or traditional providers. The only legacy element we are retaining is the address format: user@domain.

Since this is essentially a mail system powered by HTTP, we shall call the protocol HMTP: Hypertext Mail Transfer Protocol (where the "S" for Simple in SMTP is replaced by "H" for HTTP).

The Technical Blueprint

The beauty of this design is that it doesn't invent any new technology; it simply assembles existing, battle-tested tools.

The Bill of Materials

By utilizing these standards, we solve several infrastructure hurdles immediately:

• TLS, SNI, and Virtual Hosting: Provided for free by the web stack.
• Standardized Status Codes: We don't need a new vocabulary.
• Existing Infrastructure: Compatible with Nginx, load balancers, and every major programming library.

The HTTP Status Catalog

HMTP leverages existing codes to manage mail states:

• 202 Accepted: Message queued for delivery.
• 429 Too Many Requests: Rate limiting (utilizing the Retry-After header).
• 404 / 410: Mailbox is unknown or has been deleted.
• 3xx: The mailbox has relocated.
• 413: Payload too large.
• 402 Payment Required: A code reserved since 1997, perfect for paid anti-spam services.

Essentially, the protocol ceases to be a "new server" and becomes a convention over HTTP, similar to Micropub or Webmention.

Discovery and Delegation: A Modern MX

Instead of relying on DNS MX records, delegation is handled via a static JSON document.

Request: GET https://example.com/.well-known/hmtp/ana

{
  "inbox": "https://mail.migadu.example/hmtp/inbox/ana",
  "keys": {
    "public_key": "...",
    "sigchain": "..."
  }
}

This approach allows for per-user delegation—meaning every single mailbox on a domain could theoretically be hosted by a different provider. This is something MX records cannot do. We can implement this using WebFinger (RFC 7033), which is already proven to scale via Mastodon.

Identity and Key Rotation

Identity should not be tied to a specific key (as keys can be lost or expire); instead, identity is something that keys back to.

1. Cryptographic Continuity

We use a sigchain. The discovery document lists the current key and a history of rotations. Each new key is signed by the previous one. Mathematically, if $K_n$ is the current key, the transition to $K_{n+1}$ is verified as: $\text{Verify}(K_{n+1}, \text{Signature}_{K_n}(K_{n+1})) = \text{True}$ This allows anyone who trusted you at step $N$ to trust you at step $N+1$ without a third party.

2. Domain Control Fallback

If a device is stolen and the chain is broken, the domain owner can declare a new key. This triggers a mandatory announcement period (e.g., 30 days) where servers warn users: "Identity re-anchored by domain, not by signature."

Warning: Domain-anchored identity is fragile because domains are rented, not owned. If a domain expires and is poached, the new owner can impersonate the previous user. ATProto addresses this by using DIDs to decouple identity from the domain.

Delivery via Store-and-Forward

Delivery is a simple POST request to the recipient's inbox:

POST /hmtp/inbox/ana HTTP/1.1
Host: mail.migadu.example
Content-Type: application/hmtp+json

{
  "envelope": { ... },
  "body": "sealed_content_here"
}

To maintain the reliability of email, we use a store-and-forward model. Your client sends an authenticated POST to your own server's outbox. Your server then handles the queue, managing exponential backoff and honoring Retry-After headers.

To prevent duplicates, every message ID is a hash of its content: $\text{MessageID} = \text{Hash}(\text{Content})$ This ensures that retries are idempotent; the receiving server simply deduplicates by ID.

Delivery Lifecycle Diagram

---

Visual References