Skip to main content
OxiMail is a mail and collaboration server written in Rust. It is a single binary that speaks JMAP as its primary protocol, alongside SMTP, IMAP, CalDAV, CardDAV, and ManageSieve. One server, one configuration file, one process gives you mail, calendar, contacts, tasks, file storage, and chat, all backed by the same storage engine. It is licensed under the AGPL-3.0-or-later. This manual documents the open-source server: its protocols, its administration, and its JMAP API.

​
What makes OxiMail different

OxiMail is built from scratch around a few firm principles. They are design choices, not marketing claims.

​
JMAP-first

JMAP (RFC 8620 and RFC 8621) is the modern successor to IMAP: a single HTTPS/JSON protocol with batched requests, efficient change tracking, and push. OxiMail treats JMAP as the native protocol and exposes mail, calendar, contacts, tasks, files, sharing, and chat through it. The traditional protocols (IMAP, CalDAV, CardDAV, ManageSieve) are translated onto the same JMAP-backed storage, so existing clients keep working.

​
Fail-loud

OxiMail never fails silently. An invalid object ID returns a notFound entry, never an empty array that hides the error. An accepted email is always delivered somewhere or explicitly rejected, never quietly dropped. Errors are surfaced, logged, and returned to the caller. This is the single most important rule in the codebase.

​
No sidecars

A conventional mail stack is a constellation of services: Postfix, Dovecot, nginx, an external fail2ban, ClamAV, an anti-spam daemon. OxiMail collapses every one of those into the same binary, each as a Rust crate. There is no external daemon to install, secure, or keep in sync. The SMTP server, the IMAP/CalDAV/CardDAV gateways, the rate limiter, the ban logic, and the anti-spam pipeline all live in the one process.

​
Open and auditable

OxiMail is AGPL-3.0-or-later and built on open standards (RFCs and public IETF drafts). The code is inspectable by anyone, and there is no proprietary lock-in: your data lives in documented formats and travels over documented protocols.

​
Who runs OxiMail

OxiMail is for operators who want to keep control of their own mail and collaboration data: self-hosters, institutions, and regional operators. The operator runs the server on their own infrastructure and holds their own keys. There is no third party between the operator and the data.

​
What this manual covers

This is the manual for the OxiMail server. It documents the protocols the server speaks, how to administer it, and the JMAP API you can build against.
The OxiMail workspace (the web client) is a separate product and is out of scope here. This manual stops at the server: its protocols, its administration, and its API. Because the API is open, anyone can build a client against the documented JMAP methods.
The manual is organised into three tracks:

Operator Manual

Run it. Installation, mail and SMTP, storage, authentication and security, anti-spam, groupware, encryption at rest, multi-tenancy, TLS, migration, and day-to-day operations.

Developer / JMAP API

Build on it. The JMAP Core session and dispatch model, the method surfaces for mail, calendar, contacts, tasks, files, sharing, and chat, and the admin REST API.

Architecture Reference

Understand it. How the binary is structured crate by crate, the request paths, and the storage model.

​
A note on accuracy

This manual describes what the server actually does today, on the current v0.30.0 line. It does not present planned or experimental work as if it already shipped. Anything that is designed but not yet implemented is marked explicitly as planned. If a page says a feature exists, the server does it.