Files

T

mix 7ef7f75246 release: 1.9.2: Review pass: port-25 milters, DMARC validation, rate-limit fix

Review pass over `1.4.0`…`1.9.1`: port 25 no longer shares the submission milter chain, DMARC reports are validated before they are stored, and the auto rate limit is correct for a non-default level-1 window. Schema migration `0010` (index only). Upgrading is a tag bump.
Added:
  - SQLite migration `0010_send_log_app_login_index.sql` —
  - DMARC aggregate reports are accepted as **zip** as well as gzip or plain XML
  - e2e: `checkPort25ConfigCombinations` regenerates the Postfix configuration
Changed:
  - README hero line and a **Positioning** block in `docs/product.md` record the
Fixed:
  - The setup account's password is hashed at bcrypt cost `12` like every other
  - Login/setup rate limiter: protecting blocked buckets from eviction is now
  - `postqueue -p` output is bounded to 4 MiB (the timeout alone left the size of
  - [schema-migrations.md](docs/schema-migrations.md): the schema section was
  - postqueue reader is now time-bounded: `postqueue -p` runs under a 5-second
  … (11 more in CHANGELOG)
Changed:
  - [roadmap.md](docs/roadmap.md) now carries everything the 2026-08-19 code
  - Extracted `internal/configsafe` — the empty-value and forbidden-character
  - Build, deploy and migration comments no longer cite the archived
  - Dropped the `parseDomainRateLimitForm` / `parseAppRateLimitForm` pass-through
  - Extracted shared helpers: `internal/atomicfile` (atomic temp-write+rename) and
  … (7 more in CHANGELOG)
Removed:
  - Unused legacy asset `docs/assets/icon.png` (superseded by the four brand SVGs
  - Plan documents for already-shipped features: `domain-stats-auto-ratelimit`,

Full detail: CHANGELOG.md (1.9.2).

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

3.3 KiB

Raw Blame History

Plan: inbound-quarantine

Status: candidate — design TBD; needs explicit agreement before any code
Version: TBD (1.x MINOR if opt-in and backward-compatible; may warrant 2.x if it changes 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.md 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.
Sensible to decide after or alongside inbound-antispam-panel.md (journal/lists), but not blocked on it for design discussion.

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.3 KiB Raw Blame History