T

karti-ai aab2a8558e 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>

2026-06-21 12:07:37 -07:00

ARCHITECTURE.md

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

2026-06-21 12:07:37 -07:00

LICENSE

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

2026-06-21 12:07:37 -07:00

README.md

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

2026-06-21 12:07:37 -07:00

README.md

OpenMail

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 "AgentMail, but self-hosted and MIT-licensed." OpenMail embeds the battle-tested mail internals of 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: early WIP, private during initial build. Will be released MIT-licensed and public. Designed only from public RFCs and public API surfaces — nothing proprietary.

License: MIT — see LICENSE. Builds on Mox (MIT) and the emersion/go-* mail libraries. See ARCHITECTURE.md for the design of record.

Why

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; 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 (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.