Where each service goes¶
The server, the console and the webmail are separate programs that talk over JMAP and sign in with OAuth. Where each one runs is a decision you make, not one the software makes for you, and every arrangement below is supported.
The decision, in one table¶
| Mail server | Console | Webmail | |
|---|---|---|---|
| Open | 25, 465, 993, 995, 4190 answer anyone | 443 answers anyone | 443 answers anyone |
| Protected | 25 from the world, client ports allowlisted | 443 behind an IP allowlist | 443 behind an IP allowlist |
| Private | 25 relayed in from a front door you control | on the private network only | behind the VPN |
Port 25 is the one thing that cannot be hidden and still be a mail server: it has to answer strangers, because that is what receiving mail is. Everything else is yours to place.
Three arrangements that make sense¶
One machine¶
Everything on a single VPS, on a private Docker network, with one proxy in front. One thing to back up, one thing to update.
This is the right answer for a home lab or a small organization, and it still keeps the console off the mail server's own listeners — the mail host serves no web interface in any arrangement.
Front ends on their own host¶
Move the console and the webmail to a second machine. Now a bug in a web front end is a bug on a box that holds no mail, and you can size the two independently: the webmail scales with people reading mail, the server with mail stored and delivered.
The server's API has to be reachable from that machine, and only from it — see Security for how origins are restricted.
Three machines¶
The server, the webmail and the console each on their own hardware, with the console on an internal network or behind a VPN. This is the arrangement for a multi-tenant host, and the console is the piece that benefits most: it is the one front end nobody outside your operators ever needs to reach.
Sizing¶
Rough shape rather than numbers, because the numbers depend on your mail:
- The server wants disk and RAM. It grows with mail stored, accounts, and delivery rate. It is the piece to give headroom.
- The webmail is a small Node process that stores nothing of its own. It grows with people reading mail at the same time, not with mail kept.
- The console is a static build plus the API calls it makes. It costs almost nothing and is idle most of the time.
When one database stops being enough, the server can read from replicas and spread message storage across several stores, so growing does not mean moving to a different product.
What does not change¶
Whatever you choose:
- No web interface is installed on the mail host.
- The server decides every permission, so the two front ends cannot disagree about what someone is allowed to do.
- The console and the webmail sign in as OAuth clients the server registered for itself.