mix/selfpost

Fork 0

Files

T

mixandClaude Opus 5.5 30fcf978e0

test / test (push) Waiting to run

Details

docs: clear shipped plans and closed work out of the documents

Owner, 2026-10-18: "Надо почистить документы от устаревшего и сделанного."

- Deleted, shipped: plans/delivery-log-storage, from-header-binding,
inbound-antispam-panel, inbound-upstream-result, panel-dkim-signing,
panel-notifications, and the own-mta-builds analysis (its three rows
shipped as 2.6.1, 2.7.0, 2.8.0). What outlived them moved first: when a
filter-list counter is worth a migration, and the notifications' "when"
table, into architecture.md; the sender check's own-process trigger into
security.md. Code comments that cited them point at architecture.md or
security.md; CHANGELOG keeps their names, unlinked.
- Kept, marked closed: audit-2026-10-12, assumptions-2026-10-14 and
security-audit-2026-10-17 - the code cites their finding ids in 50-84
files. Their file:line refs are of the tree each audited.
- roadmap.md: open work only - stage H of the security audit (the owner's),
go-milter-upstream (the owner posts), and queue-table, which the
redesign left undecided and only its own shipped section still named;
Dropped and Ideas as they were. 2.x versioning instead of 1.x.
- development.md: the 47-row planned-version-cuts table (history, in the
CHANGELOG) gone; a stage's last step now removes its roadmap item and
plan. Docs map lists the closed audits.
- panel-redesign.md: the done checklist out; Room for roadmap items says
which drawn screens are unbuilt and why.
- Stale facts fixed: schema-migrations.md and architecture.md at schema 14
(0013's users columns and user_links, 0014's secure TLS mode);
security.md's accepted risk "profile saved without the password" - the
e-mail asks for it since 2.14.0.

Tests: go build, go vet; go test of cmd and the touched internal packages
pass except logtail's three Windows-bound rotation tests (rename of an open
file; CI is Linux). Only comments changed in Go.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-18 22:37:22 +03:00

3.2 KiB

Raw Blame History

Plan: inbound-quarantine

Status: an idea to think about, not on the roadmap (owner, 2026-10-12) — design TBD; needs explicit agreement before any code
Version: TBD (a 2.x MINOR if opt-in; a major only if it breaks the inbound storage or backup contract).

Goal (draft)

Let the operator hold suspicious inbound mail instead of only accept/reject at the milter — review in the panel, then release to the configured upstream, delete, or add sender to allow/deny lists.

This is a product boundary question, not a settled design. The item exists so we can compare approaches before committing.

Why it is separate from inbound-antispam-panel

inbound-antispam-panel (shipped 2.1.0; architecture.md § Mail path) covers metadata (journal + lists). Quarantine implies storing message bodies (or a durable reference to them) under /data, retention, release workflow, and a wider attack/backup surface — closer to "mini-mailbox" than pure relay.

Mockup

A target look is drawn — list and detail — in-quarantine, in-quarantine-message — under the design contract of panel-redesign.md. It assumes answers to the questions below (SelfPost holds the mail, release goes to the upstream, 14 days, headers only in the panel); it does not settle them.

Open questions (to decide before a checklist)

Where mail lives
- SelfPost store under /data/quarantine/ (panel owns lifecycle), or
- delegate to rspamd/Redis and panel only proxies release (less storage in SelfPost, tighter rspamd coupling).
What "release" means
- inject into Postfix as a new delivery to the domain's upstream transport;
- or manual download only (no automatic forward).
Retention and caps
- max age, max total bytes, per-domain limits; interaction with backup size.
RBAC
- global admin only vs domain-admin for assigned inbound domains.
Threat model
- malware in stored MIME, path traversal on extract, quota DoS on busy MX.
Product fit
- does this violate product.md "no mailboxes" if we only hold spam suspects briefly? Explicit product decision required.

Context (as-built)

Inbound relay forwards or rejects; no local delivery (architecture.md § Mail path).
Optional INBOUND_ANTISPAM_MILTER — external rspamd may quarantine on its own today, without panel integration.
DMARC p=quarantine is unrelated (outbound policy for receivers).

Likely out of scope (until revisited)

IMAP/webmail for quarantined mail.
End-user self-service quarantine (non-admin recipients).
Outbound quarantine.

Dependencies

Inbound relay, shipped in [1.4.0] — as built in architecture.md § Mail path.
Builds on inbound-antispam-panel (journal and lists, shipped 2.1.0).

Done when (placeholder)

TBD once approach is chosen. Minimum bar would include: opt-in flag, panel list/detail, release or discard action, retention, backup inclusion documented, security review.

Implementation checklist

None yet — expand this plan after the open questions above are answered.

3.2 KiB Raw Blame History