INBUXA Is Here: Why I Forked a Mail Server I Genuinely Admire

Yesterday I published Something Is Coming and then refused to answer a single useful question. How it works. What it replaces. Who it's for. When.

Today, all four — and a fifth I didn't promise, which is the one I actually care about: why a fork?

INBUXA

INBUXA is a mail and collaboration server — JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV, in one Rust binary — together with the console that administers it and the webmail people actually live in.

Every feature is in the install. No license key, no seat count, no tier above the one you already have, nothing switched off until you pay. It is free software under the AGPL-3.0, all of it, and the source is at github.com/inbuxa/inbuxa-server.

It is at inbuxa.org, which has rather more on it than it did yesterday.

The three things that were always separate

The teaser said it was three things that have always been separate, built to be one:

• INBUXA Server — protocols, storage, delivery, spam, everything that faces the internet. It holds the mail and does nothing else.
• INBUXA Admin — the console. Tenants, domains, accounts, queue, certificates, metrics, traces.
• The webmail — built from ihasmail, which some of you already run, now shipped as part of a suite instead of bolted on afterwards.

They are separate programs on the same contract: each talks to the server over JMAP and signs in with OAuth, exactly as any other client would. None of them is a web page welded to a daemon.

That sounds like an implementation detail. Hold onto it — it turns out to be the whole argument.

First, the part people skip

INBUXA Server is a fork of the Stalwart mail server, and I want to say something before I say anything else.

It is a superb piece of software. Modern mail servers are miserable to write. The protocol surface is enormous, the specifications are forty years deep and mutually contradictory in places, and the consequences of getting any of it slightly wrong land on people who just want their mail. Stalwart does JMAP properly, which almost nothing does. It is fast, it is coherent, and it was built by people who clearly know exactly what they are doing. I ran it in production, for real users, for a long time, and I chose it over the alternatives on merit.

I am not forking it because it is bad. I am forking it because I would build it differently, and because the licenses that made it possible for me to read it in the first place are the same licenses that make it legitimate for me to say so in code rather than in a mailing list post.

Every fork announcement claims to respect the original. Mine has to, because the respect is load-bearing: the reason INBUXA exists at all is that somebody did outstanding work and published it under a license that said here, and you may build on this. That is not a thing to be casual about.

Forking is how free software corrects itself

A fork sounds like a schism. In free software it is closer to a pressure valve — the ordinary mechanism by which a project that has drifted from what some of its users need gets a second answer, without anybody needing anybody's permission.

The right to fork is not a loophole in these licenses. It is the point of them. Freedom zero is to run the program; the ones that follow are to study it, change it, and pass the changed version on. A license that grants those and then expects nobody to ever use them is not really granting them. Forking is that clause being exercised as designed.

And it is not rare, or radical, or new. It is most of the software you use.

XFree86 → X.Org, 2004. For over a decade XFree86 was the X server on Linux; if you ran a graphical desktop, you ran it. In February 2004 its 4.4.0 release arrived under changed terms — a new attribution clause that the FSF and the distributions judged incompatible with the GPL. Nobody could ship it. So the community forked from the last release under the old terms, stood up the X.Org Foundation, and shipped X.Org Server 6.7.0 that April. Within about a year essentially every distribution had moved, and XFree86 — the incumbent, the default, the one with the decade of history — became a footnote. Not because the fork was better on the day it was made. It was practically identical on the day it was made. It was better because of the terms it came under.

MySQL → MariaDB, 2009. Oracle acquired Sun, which had acquired MySQL AB, and Monty Widenius — the man who wrote MySQL — forked his own database rather than find out what happened next. MySQL is open core: the Enterprise edition holds proprietary pieces the community edition does not get. MariaDB's answer was to build free implementations of those pieces and put them in the one edition everybody has. Fedora made it the default in 2013, RHEL 7 followed, then openSUSE and Arch. I wrote about that divergence years before I ever expected to be doing something rhyming with it.

ownCloud → Nextcloud, 2016. This is the one that sits closest to home, because it is the same shape of software: self-hosted collaboration that ordinary people are supposed to be able to run. Frank Karlitschek, who founded ownCloud, left with most of the core developers and forked it. The stated objection was open core — capabilities held back in a proprietary edition. Nextcloud's answer was to put everything in one AGPL codebase and sell support and services rather than features. Ten years on, Nextcloud is simply what people run.

OpenOffice.org → LibreOffice, 2010. Hudson → Jenkins, 2011. Both forked out from under Oracle, both took the developers and the users with them, and in both cases the fork is now the thing everyone means when they say the name. The originals still technically exist.

And then the modern wave. Elasticsearch → OpenSearch in 2021, after a move off Apache 2.0 — and worth noting that security features like TLS and role-based access had lived in the paid tier, while the fork shipped them open from day one. Terraform → OpenTofu in 2023, forked within days of a move to the Business Source License, now under the Linux Foundation. Redis → Valkey in 2024, forked within a week of the license change, backed by AWS, Google and Oracle, with Debian, Fedora and Alpine switching almost immediately. I covered that whole wave in When the Cathedral Ate the Bazaar, and it is the backdrop to all of this.

Debian → Ubuntu, 2004. I'll end on this one deliberately, because it is the least dramatic and the most instructive. Ubuntu is not a protest. There was no license change, no acquisition, no falling out. Somebody wanted a different release cadence and a different audience, built it on Debian's work, and twenty years later both projects are alive and Debian is not remotely diminished — it turned 31 in fine health. Work flows both ways. The ecosystem got two good answers instead of one.

That is the version of forking I am aiming at.

What that history actually shows

Three things, and then the part that argues against me.

One: the fork is usually about the terms, not the code. X.Org didn't fork because it had a better renderer. Valkey didn't fork because it had a faster hash table. They forked over the conditions attached to the software, and the code followed afterwards. Disagreements about terms cannot be resolved with a patch. A fork is the only expression available.

Two: the ecosystem moves faster than anyone expects. A week for Valkey. Days for OpenTofu. A year for X.Org to unseat a decade-old incumbent. When the terms and the needs separate far enough, the migration is not gradual.

Three: it is not zero-sum. Debian and Ubuntu. MariaDB and MySQL, both still shipping. Forks create duplicated effort, which is a real cost, but they are not an attack, and treating every one as an act of aggression has done free software no favours.

Now the honest part. Most forks fail. For every X.Org there are a hundred that got a flurry of attention, diverged for six months, and quietly stopped tracking upstream until they were an unpatched liability wearing a project's name. And I argued in When the Cathedral Ate the Bazaar that every one of these forks fragments the bazaar a little further — communities split, adopters have to pick sides, effort gets spent twice. I still think that. It is the strongest argument against what I have just done.

So a fork needs an actual reason. Not a preference. A difference you cannot patch your way to. Here are mine.

Why this one

1. Security, which is really a question of where things run

A web interface is the single most-attacked surface in a mail deployment. It takes untrusted input from the open internet, it holds sessions, it renders content that arrived from strangers. And in the normal arrangement it is running on the machine that holds everyone's mail.

INBUXA puts none on that machine. No web interface is installed on the mail host and none is fetched at first boot. /admin and /account answer 404 — in bootstrap mode and after setup alike. The console and the webmail are separate services that must prove who they are before the server will answer them, and the server's API answers only the origins you have named. First boot runs entirely over JMAP, because there is no web server there to serve a setup wizard.

The mail host does mail. That's the whole job. Everything else is somewhere else, and "somewhere else" is a decision you make.

2. Topology, which is the same argument wearing different clothes

This is the difference that is hardest to retrofit and easiest to underrate.

Because the three pieces are separate programs speaking JMAP and OAuth over a network, where each one sits is yours to decide. Put all three on one VPS. Or keep the mail server behind protected ports, silo the console where only you can reach it, and open the webmail to the world so people can read their mail from a hotel. Or put the webmail behind a VPN and expose nothing at all.

Every one of those is supported, because none of them is a special case — they are the consequence of the pieces genuinely being separate rather than nominally separate. There is a deployment planner on the site: pick a starting point, change any row, and it tells you what you just made reachable.

You cannot get here by patching. A process with a web interface inside it can be configured not to serve one. A suite of programs on a contract is a different piece of software. That is a fork-shaped difference.

3. Freedom-licensed, in one edition, with nothing held in reserve

I moved to Linux in 1996 to get out from under licensing, and thirty years later I am still making the same choice for the same reason.

INBUXA is AGPL-3.0. One edition. What you install is all there is. The license asks one thing back: if you change it and run it for other people, those people are entitled to your version of the code, the same way you are entitled to mine. That is the deal I took upstream's work under, and it is the deal I am passing on.

4. And I have no patience left for feature gating

Here is the part I will not be diplomatic about.

Look at what tends to sit behind the paywall in server software. Multi-tenancy. Directory integration. Provisioning. Audit and monitoring. Scale-out storage. Sometimes, unbelievably, transport security and access control.

Every one of those is a thing you need the moment you stop running software for yourself and start running it for other people. That is exactly, precisely, the worst place in the entire stack to draw a line and start charging — because it is the line where a hobbyist becomes a host. It is the school, the co-op, the union branch, the activist group, the village hall, the sysadmin carrying mail for their family and three friends. It is the person who is least able to pay and whose users are most exposed if they cut the corner instead.

The business logic is obvious: charge where the value is, and the value appears when there are other people involved. I understand it. I do not have to like it, and I have watched it play out often enough to be completely out of sympathy with it. Gating multi-tenancy is a decision that the small host either pays or does without isolation between the organizations they carry. Gating a directory integration means they either pay or manage accounts by hand. Gating audit means they either pay or cannot tell you what happened.

So: tenants, masked addresses, undelete, SCIM provisioning, per-domain directories, branding, monitoring and live tracing, scale-out storage. They are in the install. Not one of them checks a license before it runs, because there is nothing to check. What a mail server for a household needs and what one for a hundred organizations needs are the same install, and the belief underneath that is simple —

the features you need in order to host mail for other people should belong to everyone who runs a mail server.

That is not a complaint I can file. It is a piece of software or it is nothing.

What a fork owes

If the right to fork is the point of the license, the obligations are the price, and I would rather be visibly strict about them than argue about them later.

Take only what was given. Upstream's files are dual-licensed, and INBUXA takes them under the AGPL-3.0. That is the grant, and it is the whole grant.

Build the rest yourself, properly. The feature list above was not lifted from anywhere. Every one was rebuilt clean-room: a written specification first, dated and committed before a line of its implementation existed, drawn from public documentation, the published standards, the RFCs and observed behaviour — and then implemented from that specification. Every upstream import is stripped before it lands, by a tool built on upstream's own, and the report for every import is in the repository. The specifications are in docs/spec/features/ and the reports are in docs/fork/strip-reports/. They are published so you can check the claim instead of trusting me.

Keep the notices. Upstream's copyright notices stay on every file they cover, and every file this fork changed says so in its own header, beneath the notice it arrived with.

Say plainly what it is. Stalwart is a trademark of Stalwart Labs LLC. INBUXA is not affiliated with, or endorsed by, Stalwart Labs. inbuxa --version names the upstream base it was built from, and so do the startup banner, the release notes and the documentation — mail store upgrades are one-way, so you should always be able to see which format your data is about to be converted into before you convert it.

Don't be a liability. The failure mode of forks is abandonment. INBUXA runs my mail and other people's, which is the only commitment device I actually trust.

The AI question, answered before you ask it

INBUXA has exactly one AI feature, and I would rather describe it than dodge the word.

The spam filter can take a language model's opinion as one signal among senders, content and reputation, and a Sieve function can ask a model directly. That is all of it.

It is off in a new install — nothing configured, nothing preset to a hosted provider. It is built for a local model you host and can audit. It sees a message's subject and text and nothing else, what it sees is never logged, and a slow or failing model is skipped rather than queued: mail does not wait on a GPU.

You may point it at a hosted endpoint if you want to. That is your call, which is exactly why I won't tell you message content can never leave your network — the moment an operator configures a remote model, that would be a lie.

Two ways in

Starting fresh. Build the server, or build the container image from the same tree:

cargo build --release -p inbuxa

A server started with no configuration comes up in bootstrap mode, and INBUXA Admin's setup wizard takes it from there — the administrator, your domain, its DKIM keys, ACME certificates and a first mailbox, entirely over JMAP. There is no web interface on the mail host to walk through, so the console does the walking from wherever you chose to put it.

Already running Stalwart. The data format is unchanged, so moving across is a copy rather than a conversion: accounts, passwords, live sessions, certificates, tenants and mail all arrive intact, and nobody re-enters a password or re-authorizes a client. The old install is stopped but left standing, and it is what a rollback returns to.

And the honest part. Both of those are written out step by step, and both are things you run yourself today. The single-command installer is specified and not yet built, and the migration tool is specified and not yet built — INBUXA's own cutover was done by hand, in a 78-second window, and what that run took is exactly what those two tools are being built to automate. I would rather tell you that than ship you a command that does not exist.

Both routes are written out step by step at docs.inbuxa.org.

Go and have a look

• The site: inbuxa.org
• The source: github.com/inbuxa/inbuxa-server
• The docs: docs.inbuxa.org
• Me: @[email protected], or the feed

X.Org was not better than XFree86 on the day it forked. It was identical, under terms people could live with, and that turned out to be the entire difference.

I'll settle for that.

Something was coming. It's here.