Architecture v2: embed Mox (MIT) as a library; native Postgres agent layer

- Choose Option B: single binary embedding Mox's stateless protocol/crypto/
  delivery packages (dkim, spf, dmarc, dane, mtasts, message, smtpclient, junk,
  dsn, anti-abuse) while owning server loop (go-smtp) + Postgres data model.
- Boundary rule: never import mox smtpserver/imapserver/queue/store/config
  (bbolt/global-config coupled) — that's the line between embed and fork.
- Add MIT LICENSE; reframe README as a real MIT OSS product.
- Deliverability moat leans on mox smtpclient+dane+mtasts; relay fallback.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

README.md

@@ -1,38 +1,49 @@
 # OpenMail
 
-A self-hosted, AI-native mailbox for agents — open-source infrastructure that gives an AI agent its
-own real email inbox (receive, parse, thread, search, send) on a box you control.
+**An agent-native, self-hosted mail server.** One Go binary that gives an AI agent its own real
+email address — receive, parse, thread, search, and send actual SMTP mail on a box you control —
+behind a clean REST API and an MCP server.
 
-Think "Gmail for agents, self-hosted." A single Go service + Postgres + object storage you run on a
-VPS, exposing a clean REST API (and an MCP server) so any agent can own an address, read its mail as
-structured threads, and reply.
+Think "AgentMail, but self-hosted and MIT-licensed." OpenMail embeds the battle-tested mail
+internals of [Mox](https://github.com/mjl-/mox) (also MIT) for the hard, correctness-critical
+plumbing — DKIM, SPF/DMARC, DANE + MTA-STS secure delivery, real-world MIME parsing, spam
+filtering — and layers a native, agent-shaped data model (Postgres + object storage) and API on top.
 
-> **Status: private WIP.** This is a personal learning project and a self-hosting alternative in a
-> space that hosted products (e.g. AgentMail) serve well. Keep it private. Don't reference it in any
-> job application, PR, or interview, and shelve it if it would ever conflict with an employer. It was
-> designed only from public API surfaces and public RFCs — nothing proprietary.
+> **Status: early WIP, private during initial build.** Will be released MIT-licensed and public.
+> Designed only from public RFCs and public API surfaces — nothing proprietary.
 
-See **[ARCHITECTURE.md](./ARCHITECTURE.md)** for the design.
+License: **MIT** — see [LICENSE](./LICENSE). Builds on Mox (MIT) and the `emersion/go-*` mail
+libraries. See **[ARCHITECTURE.md](./ARCHITECTURE.md)** for the design of record.
 
 ## Why
 
-The hard, valuable part of an agent-mailbox product is not the API — it's the mail plumbing:
-receiving over SMTP/MX, sending with real deliverability (SPF/DKIM/DMARC, IP reputation), parsing
-MIME, threading, and storage at scale. OpenMail is an exercise in building that plumbing properly,
-self-hostable, with an agent-first API on top.
+The valuable, hard part of an agent-mailbox product is not the API — it's the mail plumbing:
+receiving over SMTP/MX, *sending with real deliverability* (SPF/DKIM/DMARC, DANE/MTA-STS, IP
+reputation), parsing messy MIME, threading, and storage. Hosted products (AgentMail and similar)
+solve this well but are closed and run on someone else's infrastructure. OpenMail's bet: you can
+**embed** an existing MIT-licensed, production-grade Go mail stack instead of rebuilding it, and
+spend your effort on the part nobody has done well — the **agent-native** layer.
+
+## What makes it agent-native
+
+- **Persistent inboxes as first-class API resources**, provisioned in one call.
+- **Structured threads**, not raw IMAP — `In-Reply-To`/`References` stitched into conversations.
+- **`extracted_text`** — reply content with quoted history stripped, so an agent reads the new part.
+- **MCP server** — an agent (Claude Code, etc.) owns and operates its mailbox directly as tools.
+- **Webhooks + WebSocket** `message.received` events — agents react to mail in real time.
+- **AgentMail-API-shaped** REST where reasonable, so existing tooling points at a self-hosted base URL.
 
 ## Goals
 
-- **Self-hostable** in one `docker compose up` on a single VPS, scaling to a small fleet later.
-- **Agent-first API** — persistent inboxes, structured threads, `extracted_text` (quoted-history
-  stripped), labels, search, drafts, webhooks/WebSocket events.
-- **AgentMail-API-shaped** where reasonable, so existing agent tooling/MCP can point at a self-hosted
-  endpoint with minimal change. (Compatibility is a non-goal where it conflicts with a cleaner design.)
-- **Deliverability taken seriously** — DKIM signing, SPF/DMARC guidance, and a pluggable send path
-  (self-host SMTP **or** relay through SES/Postmark) because reputation is the real moat.
+- **Self-hostable** in one `docker compose up` on a single VPS; scales to a fleet later.
+- **Deliverability taken seriously** — self-host SMTP send with DKIM + DANE + MTA-STS via Mox's
+  delivery stack, *or* a relay backend (SES/Postmark/Resend) for inbox placement on day one.
+- **Single static Go binary** with subcommands; Postgres + S3-compatible object store as the only deps.
+- **Genuinely MIT** — every embedded dependency is MIT/BSD; no GPL/AGPL anywhere in the tree.
 
 ## Non-goals (for v1)
 
-- A hosted multi-tenant SaaS. OpenMail is self-host-first.
-- Beating a mature provider on deliverability out of the box — that takes IP warmup and time.
-- A webmail UI. The product is the API + MCP; humans use their own client or the CLI.
+- A hosted multi-tenant SaaS. OpenMail is self-host-first (multi-tenant `pods` exist, but you run it).
+- A full webmail UI. The product is the API + MCP; humans use their own client.
+- Beating a mature provider's deliverability on day one — self-host IP reputation takes warmup + time;
+  the relay backend exists for exactly that gap.