Security¶
The design has one idea in it: the machine that holds the mail does mail, and nothing else.
No web interface on the mail host¶
A web interface is the part of a mail server most often attacked, and it is the part a mail server needs least.
INBUXA installs none on the mail host and fetches none at first boot.
/admin and /account answer 404, in bootstrap mode and after setup alike.
Administration is INBUXA Admin's job, and the webmail is its own
service; both are deployed separately and can live on another machine
entirely.
An install upgraded from Stalwart keeps what it had
If the server you migrated from had a web application configured, it comes across with everything else — the store is copied as it is. Remove it deliberately if you do not want it.
The API answers only the origins you name¶
The server's API answers cross-origin requests only from the console and
webmail origins you configure. An unrelated web page in someone's browser
cannot call it, which is the attack that a permissive Access-Control-Allow-Origin
would leave open.
Set those origins when you install, and again if you move a front end to a different hostname.
Only apps you registered can sign anyone in¶
The console and the webmail sign in with OAuth — authorization code with PKCE — as first-party clients the server registers for itself on first boot.
Client registration is required, from the first boot, which means an application the administrator has not registered cannot start a sign-in at all. A phishing page cannot borrow the real sign-in page to collect credentials, because the server will not issue a code to a client it does not know.
Anything that is not first-party goes through a consent page naming it.
The server decides every permission¶
Neither front end decides what anyone may do. Both ask, and the server answers, so the two can never disagree — and a tenant administrator sees their own tenant wherever they sign in, by whichever route.
This is also what makes switching protocols off reliable rather than cosmetic.
Getting back in¶
A settings change can lock the front ends out: a bad listener, a bad certificate, an IP ban that caught you.
INBUXA Admin has a recovery mode that reaches a server listening on loopback alone, so you can fix a listener or a certificate without a web interface ever being served by the mail host.
The recovery admin variable
A recovery administrator set by environment variable is honored only in bootstrap and recovery mode, and the server logs a warning if it is set at any other time. Do not leave it set on a running server: take it out of the unit once setup is done, not just out of the running container.
What the AI feature does and does not send¶
The spam filter can ask a language model for an opinion, as one signal among senders, content and reputation. It is off in a new install: there is no model configured, and nothing is sent anywhere until an administrator creates one.
When one is configured:
- only the subject and the message text are sent — never the envelope, the addresses, other headers, the client IP, attachments or images;
- message content is never written to the logs;
- a model that is slow or failing is skipped rather than queued, so mail never waits on it.
No URL, model name, prompt or example anywhere in INBUXA points at a hosted provider. You can point it at one — including a hosted OpenAI-compatible endpoint — and if the address is not on your own network the server warns you at startup and on every change, and the console repeats the warning on the model's form.
That warning is a warning, not a block
The check never refuses an endpoint you chose. If you configure a hosted model, message content goes to it. Nothing is preset to one, and nothing goes anywhere you did not configure.