Files

T

mix 0730b2090e release: 1.3.0: 1.3.0-1.3.1: security pass, queue persist, full backup layout

[1.3.0]
Security and quality after 1.2.5: domain-admin send-log authorization, fail-closed sign-in and application delete, level-2 rate-limit race fix, restore Resync, expanded tests, operator docs, release CI, and OFL for IBM Plex. Upgrading from 1.2.x is a tag bump; no migration.
Added:
  - licence: the SIL Open Font License 1.1 text now travels with the IBM Plex
  - docs: agreed roadmap item **queue-retries** — show this Postfix's retry
Security:
  - The independent security review of the send-log authorization and
Fixed:
  - test (e2e): send-log status scrapers follow the badge markup in
  - security (panel): the Deliveries list is scoped to a domain administrator's
  - mail (level-2 rate limit): the ceiling is no longer overshot by messages that
  - panel (sign-in): a session that cannot be written to the database no longer
  - panel (applications): deleting an application removes its SASL credentials
  … (2 more in CHANGELOG)
Changed:
  - docs: operator and as-built docs aligned with the code after a full
  - docs: [guide.md](docs/guide.md) reorganised into **Installation**, **Instance
  - docs: the 2026-08-13 full-tree review plan is complete — every phase (P0–P7)
  - licence: [NOTICE](NOTICE) tells modifiers to update `SourceURL` in
  - ci: the release image is published only for a **published** GitHub Release
  … (9 more in CHANGELOG)
[1.3.1]
Retry policy in the panel, persistent Postfix queue, and self-contained full backups. Mail queue and delivery history show this Postfix's first retry, backoff cap, and queue lifetime. Deferred mail survives container recreate. Full backups now archive `data/`, compose, `.env`, and `certs/`; the archive layout breaks 1.3.0 flat backups (unpack those with `tar xzf backup.tar.gz -C ./data` as before). Upgrading from 1.3.0 is a tag bump; no schema migration.
Added:
  - Mail queue and a delivery's history show this Postfix's retry policy
  - docs: **Plan checklists** in [development.md](docs/development.md) — format,
  - docs: **Implementation checklists** with model routing in
  - docs: roadmap candidates **send-log-retention** (panel Settings for delivery
  - Postfix queue under `/data/postfix/queue` — deferred and active mail survive
  … (1 more in CHANGELOG)
Changed:
  - **Breaking:** full-backup archive layout — paths are prefixed with `data/`;
  - docs: operator guide, architecture, security, and backup UI updated for
  - docs: HTML mockups for a full panel UI refresh
Changed:
  - docs: panel UI mockups after review — Status restored to live readings
  - docs: panel UI design system and mockups rebuilt as separate pages
  - docs: panel UI mockups — add-domain sits in the list card (Domains and
Fixed:
  - ci (GHCR): per-arch package tags (`X.Y.Z-amd64`, `X.Y.Z-arm64`) are dropped

Squashed CHANGELOG sections: [1.3.0], [1.3.1].

Full detail: CHANGELOG.md (1.3.0, 1.3.1).

2026-09-22 15:24:52 +03:00

4.2 KiB

Raw Blame History

SelfPost — product boundaries

What this file is. Stable product definition for SelfPost v1.0: purpose, deployment assumptions, explicit out-of-scope items, and the multi-domain model. User-facing overview in README.md; install and operations in guide.md; as-built technical detail in architecture.md.

Purpose

SelfPost is a self-hosted outbound SMTP relay with a web control panel, shipped as a single Docker image. It sends mail directly to the internet from your own IP with per-domain DKIM signing.

Primary workflow: configure the relay once (domains, DKIM, SASL applications), then point scripts and apps at the SMTP endpoint. SelfPost delivers as the configured sending domain.

Deployment context (fixed assumptions)

These constraints are intentional; changing them requires an explicit product decision:

VPS or home server — one image for both. Raspberry Pi and similar boards are not a current target but not ruled out forever.
Send from your own IP (DIY) — no intermediate relay provider. Requires outbound port 25, static IP, and configurable PTR/rDNS from the operator.
Single container — Postfix, OpenDKIM, and the panel run under one supervisord inside one image.
Panel is internet-facing — mandatory security requirements in security.md.

Infrastructure the operator provides (not SelfPost features): unblocked outbound TCP 25, static IP, PTR/rDNS, acceptable IP reputation. SelfPost does not detect, bypass, or compensate for missing prerequisites; mail simply fails to deliver when they are absent.

Out of scope

Explicitly excluded to prevent scope creep:

Inbound mail (IMAP/POP3, mailboxes, delivery to user inboxes)
Webmail
Organisations / tenancy beyond global + domain-admin roles; managing multiple sending domains under one global administrator is in scope (see below)
Inbound antispam/antivirus (rspamd, ClamAV, etc.)
A custom MTA — Postfix is used as-is
Dovecot or a full mail stack for SASL — Cyrus SASL (sasldb2) only

The domain-admin role ships in the current line (global administrator plus domain administrators with assigned domains). The optional inbound relay is the main agreed 1.x+ extension still on the roadmap — it targets a 1.x MINOR bump by default; a 2.x major remains possible pending implementation. Items marked candidate in the roadmap require explicit approval before coding (including send-log retention in Settings, 30-day send statistics, and auto level-2 rate limits — see linked plans there).

Multi-domain model

SelfPost is a multi-domain outbound relay. Two linked entities:

Sending domain

Example: example.com. Has its own DKIM key and selector.

Application (account)

A SASL login/password bound to one domain. A domain may have several applications (e.g. newsletter vs alerts), each with its own credentials, but each may send only from its own domain, never from another.

From-address mode (per application)

Set when creating or editing an application:

Any address in the domain — *@example.com (wildcard in smtpd_sender_login_maps).
Explicit address list — only listed From addresses within the domain; anything else is rejected even if it belongs to the same domain.

In both modes the From address must belong to the application's domain.

What the panel manages per domain

DKIM key + selector (shared by all applications on that domain)
One or more applications (SASL credentials + From mode + optional rate limits)
DNS guidance (DKIM TXT; reminders for SPF/DMARC)

Adding a domain does not create an application automatically.

Lifecycle

Add domain — record, DKIM key, DNS instructions; no application yet.
Add application — SASL pair (password shown once), From mode, map entries, postfix reload.
Delete domain — removes DKIM key and all its applications.
Delete application — removes only that app's SASL and map entries.

This is not multi-tenancy; it is one owner (or a small team with global and domain-scoped roles) operating several sending domains with independent application credentials.

4.2 KiB Raw Blame History