Files
selfpost/docs/plans/domain-admin.md
T
mix 75207f0d1e release: 1.0.0: Public 1.0 image; delivery log; docs and SECURITY.md (incl. 1.0.1)
[1.0.0]
Added:
  - A **Delivery log** on each delivery's page (`/deliveries/{id}`): the
  - A **History** block on the same page: the journal's two timestamps stated as
Fixed:
  - Postfix config: copy TLS cert/key from the (often `:ro`, host-owned) mount
  - Postfix config: allow `maillog_file` under `/data` via
  - E2e: read `/data/setup-token` via `docker compose exec` (file is `0600`
  - Entrypoint: check `SELFPOST_HOSTNAME` before `/data` setup (so a bad identity
  - E2e gate: wait for host-published `/healthz` before panel setup, and stop
  … (3 more in CHANGELOG)
Changed:
  - Document what `.spbk` and `.spde` stand for (SelfPost backup / SelfPost domain
  - Docs aligned with the code: setup URL is `/setup/<token>` (README and
  - Full backups no longer carry `/data/log`. It is Postfix's raw log plus its
  - Monitoring screens (status, mail queue, system log, deliveries) use adaptive
  - Documentation package consolidated into `docs/development.md`: Documentation
  … (4 more in CHANGELOG)
[1.0.1]
A documentation and packaging release: no change to the mail path, the database, or the on-disk layout. Upgrading is a tag bump.
Added:
  - `SECURITY.md` — how to report a vulnerability privately (GitHub private
  - [docs/plans/](docs/plans/) — one document per agreed extension: the optional
Changed:
  - The panel's **Account** entry is now called **Settings** — nav link, page
  - The signed-in name in the panel's nav is now labelled `User:`, so it reads as
  - [docs/product.md](docs/product.md) reframes the future line: the inbound
  - [docs/security.md](docs/security.md) is now in English, matching the rest of
  - The README documentation table now points at `SECURITY.md` for reporting a
  … (2 more in CHANGELOG)
Fixed:
  - The panel's static assets are served with a content ETag and

Squashed CHANGELOG sections: [1.0.0], [1.0.1].

Full detail: CHANGELOG.md (1.0.0, 1.0.1).
2026-09-22 15:24:51 +03:00

2.7 KiB

Plan: domain-admin (domain administrator role)

Status: agreed
Version: target bump 1.x MINOR, given a compatible migration of the current administrator into a global one.
Order: recommended after web-split, before inbound-relay.


What this is

Today the panel has exactly one subject: requireAuth is a boolean gate, not a role (web.go — the mux.Handle("/", s.requireAuth(authed)) wrapper), and the session carries nothing beyond the fact of being signed in.

The role grants access to explicitly assigned domains (one or several); the list of domains is set by the global administrator. For each domain on that list:

  • that domain's applications (creation, sender mode, password regeneration, deletion, its own L2 limit);
  • the domain's DKIM/DNS status;
  • the send log filtered to the domain — the filter already exists in the log (sendLogData).

What stays outside the role is what is global by nature:

  • adding and removing domains;
  • creating domain-admin users and assigning domains to them;
  • /reload;
  • the full backup (that is all of /data including sasldb2, i.e. every domain at once);
  • the queue and the mail.log tail — those are server-wide and not tied to a domain.

Why this extends v1.0

product.md puts "multiple panel users, roles" out of scope (one administrator). A second subject is a deliberate widening of the project's boundary, as inbound-relay is.

The cost is phase-sized, not patch-sized:

  • a users table and their binding to domains;
  • the role in the session;
  • authorisation in every handler (not only on the route — today {id}/{aid} are checked for nothing beyond existence);
  • reworking first-run setup and password change for several users;
  • accounting for the new subject in backup and domain export.

(The earlier wording of this item — "2FA and multiple administrators" — has been replaced: 2FA is off the table, and "multiple administrators" is narrowed to one specific role, because what is needed is not a second all-powerful admin but limited access for the owner of one or several domains, with the list set by the global administrator.)

Done when

  • A global administrator and a domain-admin with different rights both work through the panel; the domain-admin cannot reach past the assigned domains;
  • the current single admin migrates into a global one without losing access;
  • backup/restore accounts for users and their bindings;
  • build/vet/test/image green.

Risks

  • An incomplete {id}/{aid} check in a handler — access leaking to someone else's domain;
  • breaking setup or backup — that would be a semver major, not 1.x.