Mailwright

Why it exists

I built Mailwright because the available options for self-hosted mail were inadequate. The established open-source ecosystem consists of disparate, old, and unintegrated single-purpose systems for transport, delivery, filtering, and groupware. Each system has its own configuration and long-standing performance problems. The small number of modern alternatives are freemium products with constrained open-source editions and viral licenses. Neither approach provides a self-contained replacement for a Google enterprise email account that places mail hosting, groupware, calendaring, contacts, and spam filtering under one administration interface.

I wanted a system that was massively scalable, highly performant, modern, and fully integrated but did not impose those licensing constraints. Mailwright meets these requirements by hosting mail, running groupware, filtering spam with current techniques, and operating as an MTA with an administration interface designed for multi-tenant, multi-domain environments.

What it is

Mailwright is a mail and groupware platform. Its current implementation is a single Rust server process, which is the deliberate MVP form for a system designed to scale out into services on a Kubernetes platform. The transport layer is an SMTP and LMTP MTA that includes a durable queue, DKIM signing, DANE and MTA-STS outbound policy, and DSN generation. It provides mailbox access through IMAP4rev2 (including CONDSTORE, QRESYNC, and IDLE), POP3, and JMAP Core and Mail, with push delivered over WebSocket and EventSource. A Sieve engine provides server-side filtering and can be managed by clients through ManageSieve.

The groupware component is a WebDAV, CalDAV, and CardDAV server with a twenty-privilege ACL model and iTIP/iMIP scheduling, which allows calendar invitations, replies, and free-busy queries to operate between users and across organisations. Spam filtering uses SPF, DKIM, DMARC, and ARC verification together with a Bayes-and-heuristics analysis pipeline that can be tuned for each deployment. Authentication uses a built-in directory with OIDC and OAuth2 bearer support, while ACME automatically issues and renews TLS certificates. An HTTP API and operator CLI provide administration for installations that host many domains and tenants.

How it works

The server runs as one process and uses role-based storage. Data, blobs, full-text search, caching, and pub/sub each use a configurable backend. A single-machine installation can use RocksDB, while deployments that need to scale out can use PostgreSQL, S3, Redis, and NATS. The same binary supports both configurations, and the role boundaries define where the planned division into services will occur.

Telemetry is based on a single typed event model in which each event generates structured logs, metrics, and traces from one emission point across a catalogue of several hundred named events. The configuration system includes an expression language that compiles into per-message conditionals. Routing rules, recipient policy, and spam thresholds use this language, which maintains multi-domain configuration in one location and format.

Architecture

Message and scheduling flows

The diagrams below trace the two flows that define a mail and groupware server. The first covers an inbound message from the peer connection to the client notification, and the second covers a calendar invitation from the organizer's save to the attendee's reply. The state panels beneath the flows present three associated lifecycles: the read states of the SMTP session, the delivery lifecycle and DSN categories of a queued recipient, and the per-recipient SCHEDULE-STATUS vocabulary specified by RFC 6638.

Where it is going

The single process is the MVP, while operation at enormous scale remains an explicit goal of the project. The current design work decomposes Mailwright into a multi-service application on Kubernetes. Its protocol surfaces, queue, delivery, filtering, and groupware stack will operate as independently deployable and independently scalable services. The role-based storage architecture supports this design because components that already access data, blobs, search, cache, and pub/sub through separate backends can be divided without re-plumbing their state. The service decomposition remains in design, and the monolithic server remains the supported deployment while that work proceeds. As a result, a current single-box installation carries forward into the scaled-out model.

Why it matters

Organisations seeking to leave hosted email currently must either assemble aging single-purpose services or use the limited open-source edition of a freemium product. Mailwright provides the full set of functions, from the MTA through calendaring and spam filtering to the admin API, in a single system that runs on user-controlled hardware. It is currently in alpha. Transport, IMAP, POP3, and filtering are its most complete areas, while the groupware stack remains under active development. Its intended scope includes everything provided by an enterprise mail account.