mixandClaude Fable 5.1
d83d326217
Header. The navbar carries the wordmark instead of the stamp - at nav size the stamp dissolves into the brick bar - and under the bar runs the stamp's paper margin with the perforation along its outer edge: round holes, flat teeth, ink hairline, 8px under a 60px bar as on the mark. docs/assets/selfpost-wordmark.svg and -ink are the stamp's own outlines; the header comparison sheet is removed. Type and tables. About 40 % of the text measured under 13px. Body is 16px with two tokens under it, 14px for supporting text and 13px for upper-case mono labels and tags; Bulma's small sizes are overridden or dropped (sp-small replaces is-size-7, is-small only on a progress bar). Every table sits in a table-container, addresses break after the @, and all screens fit without scrolling at 1280px and up. Contrast. A sweep of every text node against its real ground found the solid red button at 3:1, the muted grey at 4.1:1, the amber postmark and Bulma's menu labels just under 4.5. All 33 screens now measure 4.5:1 or better. The sweep is kept as panel/audit.js and its clean output joins the evidence a restyle step must show. Account and roles. A user's e-mail is its own field (users.email in the 2.0 baseline), edited under Account and seen by the global user on the user form and list. The DMARC default report address is a user's setting, not the server's: it moves to Account with its authorization record, and a domain follows the default of a named user. Roles are labelled by reach - global, domain - and each assignment list gains All, a per-user flag that covers domains added later. Account gains Notifications for the new roadmap candidate panel-notifications; password-reset is added as a candidate too. Also: the inbound spam filter is visible where a domain user looks (a box on each inbound domain, a tag on the list, its socket on Health); the health row is compact again and splits 6/3/2; a read-only value is as tall as its Copy button; Preflight and Account lose boxes that only filled space, and the plan's layout rule and contract now forbid them. check.py gains the type floor, the table-container rule and the is-small rule, and no longer counts min-width: 0 as setting a width. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
4.9 KiB
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 SMTP relay with a web control panel, shipped as a single Docker image. It sends mail directly from your server with per-domain DKIM signing; an optional inbound relay forwards mail on port 25 without storing it.
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.
Positioning
| Text | |
|---|---|
| Stamp subtitle | SELF-HOSTED SMTP RELAY |
| Wordmark | The stamp's own letter outlines without the stamp (docs/assets/selfpost-wordmark.svg, -ink for light grounds) — for places too small for the stamp, such as the panel header |
| Tagline | YOUR SMTP. YOUR RULES. |
| Hero line (README, GitHub) | Self-hosted SMTP relay with a web panel — one Docker image, no provider. |
Brand assets and metrics: docs/assets/selfpost-proof.html.
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
supervisordinside 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 engines (rspamd, ClamAV, etc.) — SelfPost may expose a milter hook; it does not ship or start a filter
- 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
(backup-MX / forwarder on port 25) ships in [1.4.0], off by default behind
INBOUND_RELAY_ENABLE; it is relay/forward, not IMAP/webmail. Send-log
retention in Settings ships in [1.5.0]. 30-day send statistics and
auto level-2 rate limits ship in [1.6.0]. DMARC aggregate report
ingest ships in [1.7.0], off by default behind DMARC_REPORTS_ENABLE.
Items marked candidate in the
roadmap require explicit approval before coding.
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 insmtpd_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.