MailFathom

MailFathom

A brain for your mail — self-hosted, AI-native, and yours alone.

[!WARNING]

MailFathom is under active development, and nothing between two releases is guaranteed to stay compatible until version 1.0.0. Any release before it may change the MCP tools, the configuration, the database schema, or the deployment in a breaking way — up to a release that cannot run over the previous one's configuration or data at all. Read the changelog before every upgrade, and keep a backup you can go back to.

MailFathom synchronizes your IMAP accounts into a PostgreSQL database you run, indexes that copy, and serves it to AI agents as tools over the Model Context Protocol. Reading answers from your copy rather than from a mail server, and it never marks anything read there. Writing — marking, drafting, sending — is a separate act each account and each credential has to be given, and every one of them is off until you turn it on.

*One question, answered from the local copy in an ordinary chat client. The *** in these screenshots were blacked out by hand before the files entered a public repository — until you turn SensitiveContent on, MailFathom redacts nothing on its way to a client.*

Install

Docker Compose is the recommended first installation. It is the only shape that provisions PostgreSQL for you, and its defaults publish both ports on loopback, so nothing is reachable from another machine until you decide it should be.

git clone https://github.com/fathomise/MailFathom.git

cd MailFathom scripts/quick-start-compose.sh

That third line is the quick way to *try* it, not the way to run it: the script asks where your mailbox lives, writes the configuration, starts the stack, offers the schema step, records you and your mailbox, and hands you the key a chat client connects with — and what it prepares serves that one machine over plain HTTP, keeps its credentials in files under the checkout, and backs nothing up. It prints that list when it finishes.

Installing MailFathom is the real thing: what every shape needs, and the guide for Compose, Podman Quadlet, Kubernetes, or a native systemd process. Getting started then walks from an installed instance to a first successful tool call. To evaluate from the checkout instead, the local Aspire orchestration provisions PostgreSQL and applies the schema on its own — local development has that path.

Start here

Hand the documentation to your agent

If an AI assistant is helping you install, configure, or use MailFathom, give it the documentation rather than a search over the site. One line is the whole of it:

Read https://fathomise.github.io/MailFathom/docs/llms.txt and follow it to the pages that answer my question.

That address is the current release's map: every published page, what it answers, and a link to its source, so the agent fetches the one page that owns your question instead of fragments of several. MailFathom also resolves in Context7 as /fathomise/mailfathom, which mirrors the default branch rather than a release.

→ Handing this guide to your own agent

What an agent gets

Twenty-one tools, and they are the whole surface.

Two properties hold everywhere, and much of the design follows from them:

• Reading is local. A read answers from your copy and never contacts a mail server, so it is fast, it works while the server is down, and it changes nothing remotely. Every result states how fresh the local copy is.
• Nothing writes unless you asked for it. Retrieval cannot set the remote \Seen flag at all. What can change your mailbox is what you configured — a mail rule, a spam action — or a tool a credential was explicitly granted. Sending is stricter again: it is off on every account, refused outright while the deployment is read-only, and bounded by a recipient policy and a per-period ceiling you set.

No send is performed while the caller waits. Each is written down, answered with a record identity, and offered by a delivery pass that survives a crash — so a message MailFathom says it queued is one it will actually try to deliver, and the seconds before it leaves are the only window in which it can be withdrawn. Nothing a client sends decides who a message is from.

Beside what a tool returns, MailFathom records what it can establish about each message: who authenticated its sender and whether you recognize that author, how much its text reads as machine written, and the conversation it belongs to. What each tool answers, refuses, and never repeats back is the contract.

Project status

0.8.0 is the current release, and it is the one in which a deployment stops being one person's mailbox described in a configuration file. The people it serves, their mail accounts, their credentials, and the roles that decide what each of them may do are records in your database, administered with mfctl while the deployment runs — so one deployment serves several people, shares a mailbox between them, and runs as more than one replica.

Upgrading from `0.7.0` is a new installation over a backup, not an upgrade in place. Applying the schema discards the stored mail, which synchronization fetches again, and nothing imports the mailboxes or credentials a 0.7.0 configuration declared: each is recorded again through mfctl. The changelog states each break against the surface it breaks, and what to do about it.

Nightly images are built from main and published beside the releases. A nightly is not a release: its schema can be ahead of any published migration, it has no upgrade path in either direction, and it is deleted once newer ones accumulate. What a nightly build risks states the whole of it.

Where the artifacts are published

Both registries carry the same manifest list under the same digest, so pull from whichever your environment already reaches. There is no binary artifact for the service itself: a native installation starts from a checkout.

What it does well

MailFathom is built as an enterprise-grade system from the first line, even while its feature scope is still small. Every claim below is a property of the code and the deployment assets today.

• Every act is behind a grant, and no grant implies another. Reading your mail, changing a flag, writing a draft, and sending are four separate permissions, checked when a tool is listed and again when it is called; an administrative route is checked the same way. An endpoint can also publish only some k