mixandClaude Opus 5.5
30fcf978e0
test / test (push) Waiting to run
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>
82 lines
3.2 KiB
Markdown
82 lines
3.2 KiB
Markdown
# 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](../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](../assets/panel-redesign/panel/in-quarantine.html),
|
|
[in-quarantine-message](../assets/panel-redesign/panel/in-quarantine-message.html)
|
|
— under the design contract of [panel-redesign.md](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)
|
|
|
|
1. **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).
|
|
2. **What "release" means**
|
|
- inject into Postfix as a new delivery to the domain's upstream transport;
|
|
- or manual download only (no automatic forward).
|
|
3. **Retention and caps**
|
|
- max age, max total bytes, per-domain limits; interaction with backup size.
|
|
4. **RBAC**
|
|
- global admin only vs domain-admin for assigned inbound domains.
|
|
5. **Threat model**
|
|
- malware in stored MIME, path traversal on extract, quota DoS on busy MX.
|
|
6. **Product fit**
|
|
- does this violate [product.md](../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](../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](../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.
|