A wall per organisation
The database itself keeps each organisation’s mail apart, not checks written into the app. A query with no filter returns nothing, and we test that wall before every release.
What it does
Enforced by the database
Rules in the database
Row-level security is switched on for every table that holds an organisation’s data, so the database itself says no.
No way round them
The app’s database account owns nothing and is barred from skipping the rules, even by mistake.
Tested before every release
Tests try to read and write another organisation’s rows, and they must pass before anything goes live.
Staff need your say-so
DMU staff can read an organisation’s mail only when it asks, for chosen shared mailboxes, read only and logged.
How it works
Inside the wall
- 1
The request is labelled
The server sets which organisation a request belongs to before the database is asked anything. Nothing in the request can change it.
- 2
The database filters
Every query sees only that organisation’s rows. One written without a filter returns nothing, not someone else’s mail.
- 3
Access narrows further
Inside an organisation, people see only the mailboxes shared with them. A private mailbox is read by its owner alone.
Good to know
The details
- How it is built
- Organisations share one database, kept apart by PostgreSQL row-level security rather than by separate servers.
- Private mailboxes
- Only their owner reads them. Administrators see that one exists, whose it is and whether it is connected, never its mail.
- Support access
- DMU staff open an organisation’s mail only when it asks: chosen shared mailboxes, read only, for 15, 60 or 240 minutes, after a fresh passkey check. Every opening is logged and shown to the organisation.
Be one of the first teams in
We let a few organisations into the private beta every week. Join the waitlist and we’ll email you when there’s room for your team.
Three quick questions. No card needed.