mix
75207f0d1e
[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).
4.6 KiB
Roadmap: open work (1.x+)
Status: a working tracker of extensions to the v1.0 boundary, each taken up
only after explicit agreement (product.md,
.cursor/rules/agent-rules.mdc). Detailed
design lives in plans/. Items marked candidate need an OK before
any code is written.
Reading this from outside the project: nothing here is a commitment or a release promise. There are no dates, the order is a recommendation rather than a schedule, and an item can be dropped or reshaped once its plan is written. What the project will not do is a separate question, answered in product.md — an item's absence from this file does not mean it is planned but unlisted.
Versioning: SemVer MINOR in the 1.x+ line by default (1.1.0…), as long
as defaults and migrations stay compatible with 1.0.0. A major 2.x only for
an explicit break.
Process: development.md. The history of closed phases is
in git log and CHANGELOG.md.
Index
| ID | Topic | Status | Plan |
|---|---|---|---|
| web-split | Splitting internal/web |
agreed | plans/web-split.md |
| domain-admin | Domain administrator role | agreed | plans/domain-admin.md |
| inbound-relay | Inbound relay (backup-MX / forwarding) | agreed | plans/inbound-relay.md |
| contributing | CONTRIBUTING.md |
candidate | — |
Recommended order (not binding): web-split → domain-admin → inbound-relay — first the package split, then role-wide authorisation, then the new vertical slice of the inbound relay. Deviating is allowed; there are no hard phases here.
After a context reset, pick an item marked agreed or in progress, then work
the checklist in its linked plan.
inbound-relay
Goal: optional acceptance of mail on port 25 for explicitly configured
domains, forwarded to an upstream (backup-MX / relay-forwarder). Off by default
(INBOUND_RELAY_ENABLE=false); without the flag the outbound path is
unchanged.
Boundary: an extension of v1.0 — product.md excludes inbound mail and mailboxes. This is relay/forward, not IMAP/POP3/webmail; an anti-spam engine stays outside the image, only the attachment point is provided.
Done when: see the criteria in plans/inbound-relay.md.
Dependencies / risks: a finished outbound path; open relay and backscatter;
a wider attack surface (port 25 accepting mail).
Order: recommended after web-split and
domain-admin.
Version: target bump 1.x; 2.x possible — to be settled once the
implementation lands.
domain-admin
Goal: a role with access to one or several assigned domains (the list is
set by the global administrator) — applications, DKIM/DNS, and the send log for
each of them; without global operations (adding domains, full backup, the
queue, mail.log).
Boundary: an extension of v1.0 — product.md fixes a single administrator. Not a second all-powerful admin, but limited access to the assigned domains (one or several).
Done when: see plans/domain-admin.md.
Dependencies / risks: a users table, the role in the session, authorisation
in every handler, setup and backup. Order: recommended after
web-split, before
inbound-relay.
Version: 1.x MINOR, given a compatible migration of the current
administrator into a global one.
web-split
Goal: deliberately split internal/web (or settle on keeping the package
flat) before it grows under inbound-relay and domain-admin.
Boundary: an internal refactor; the panel's behaviour for the operator does not change.
Done when: the package is split along the chosen scheme, or it is settled that it stays flat — see plans/web-split.md.
Dependencies / risks: exporting a package-private API. Order:
recommended first among the agreed features (before domain-admin and
inbound-relay).
Version: 1.x; on its own it does not force a break.
contributing
Goal: CONTRIBUTING.md in the root — the dev loop, the checks to run
before a PR, the commit protocol; development.md links to it
rather than repeating it.
Boundary: process documentation; worth writing once there is an external flow of PRs.
Done when: the file is in the root and development.md does not duplicate it.
Dependencies / risks: with a single developer and no PRs, this is low priority. Version: no bearing on semver.