fix: port-25 milter chain, DMARC report validation, auto rate-limit window

Review pass over the 1.4.0-1.9.1 work.

Port 25 no longer inherits main.cf's submission milter chain: smtpd_milters
is always overridden on smtp/inet, to the antispam milter or to nothing.
Without that, OpenDKIM (strict, tempfail) gated relayed mail during a signing
outage, and the journal-milter filed inbound mail into the outbound send log
under the sender's domain -- so Deliveries showed other people's mail and a
forged From: consumed that domain's level-2 budget. architecture.md already
described the intended behaviour; the code now matches.

DMARC reports are checked before they are stored: the policy domain must be a
configured sending domain, and must match the +tag of a per-domain hosted
address. The rua address form is predictable, so anyone able to reach it could
file reports under any domain and evict genuine ones through the retention cap.
Zip attachments are now decompressed as well as gzip.

The auto level-2 ceiling is scaled to the level-1 window before the multiplier
is applied; any window other than 3600s shifted the allowance by window/3600.

Migration 0010 indexes send_log(app_login, created_at) -- both the per-MAIL
FROM rate-limit count and the per-application statistics were scanning the
created_at range.

e2e now regenerates the Postfix config in-container for all four port-25 flag
combinations and requires postfix check to pass; the 1.9.1 crash-loop shipped
in 1.4.0 and survived three releases because only the flags-off path was
exercised.

Migration 0009 stays as shipped -- its conversion branch only fires for a
database carrying application-scope allowed_ips from before 1.9.0. The schema
reference notes that the old list was permissive and the new column is
restrictive; the guide documents the allow-list as a sending control on a
fail-open path, not an authentication boundary.

Also: gofmt across cmd/ and internal/, unused duplicate validators dropped from
internal/web/validate, export no longer swallows store errors.

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

docs/architecture.md

@@ -73,7 +73,11 @@ smtp/inet` removes Debian's stock smtpd). Outbound delivery still uses the
 - **587/submission** — only when `SUBMISSION_ENABLE=true`; STARTTLS with
   `smtpd_tls_security_level=encrypt`.
 - **25/smtp inet** — when `INBOUND_RELAY_ENABLE=true` and/or
-  `DMARC_REPORTS_ENABLE=true`. No SASL, no OpenDKIM, no journal-milter.
+  `DMARC_REPORTS_ENABLE=true`. No SASL, no OpenDKIM, no journal-milter —
+  `smtpd_milters` is always overridden on this service (to the antispam milter
+  or to nothing), because main.cf's submission chain would otherwise let a
+  signing outage defer relayed mail and would file inbound mail into the
+  outbound send log under the sender's domain.
   **Inbound relay** (`INBOUND_RELAY_ENABLE=true`): accepts only
   `relay_domains` + `relay_recipient_maps` (`reject_unauth_destination`,
   `reject_unlisted_recipient`). Maps under `/data/postfix/` (`relay_domains`,
@@ -117,9 +121,12 @@ One process, four roles:
 2. **journal-milter** — unix socket `JOURNAL_MILTER_SOCKET`; records From/To/
    Subject/SASL user at DATA; enforces level-2 rate limits; **fail-open**
    (`default_action=accept`) so milter failure does not stop mail. Domain
-   ceilings apply to every client IP; an application ceiling with trusted IPs
-   raises the limit for those IPs only and skips the domain check (guide § Rate
-   limiting). The level-2 count is the stored send-log rows plus the messages
+   ceilings apply to every client IP; an application ceiling **overrides** the
+   domain one for that login, higher or lower (guide § Rate limiting). Since
+   1.9.0 the client IP allow-list is a separate, restrictive control on the
+   application (`applications.auth_ip_restrict`), checked here at `MAIL FROM`
+   and fail-open like the rest of this milter — not an authentication
+   boundary. The level-2 count is the stored send-log rows plus the messages
    this process has admitted but not yet written (`internal/milter/inflight.go`),
    so concurrent sessions cannot each spend the same last slot; a reservation
    is released at end-of-message, on ABORT, or after a 10-minute TTL.

docs/guide.md

@@ -729,6 +729,13 @@ only sees SelfPost. Default action is fail-open (`accept`) so a down sidecar
 does not block backup-MX; set `INBOUND_ANTISPAM_MILTER_ACTION=tempfail` to
 defer instead.
 
+**Inbound mail is not in Deliveries.** Port 25 runs its own milter chain: the
+optional anti-spam milter, and nothing else. OpenDKIM does not sign relayed
+mail (and a signing outage therefore cannot defer it), and the journal-milter
+does not file it — [Deliveries](#deliveries) stays a record of what *you* sent.
+This also keeps a forged `From:` on inbound mail from counting against a
+sending domain's [level-2 rate limit](#rate-limiting--level-2-domain-and-application).
+
 Inbound configuration lives in SQLite and `/data/postfix/` map files, so it
 is included in a [full backup](#full-backup-and-restore). Single-domain
 export/import is sending domains only.
@@ -768,6 +775,15 @@ alone, `check_recipient_access` permits only configured report addresses;
 everything else is rejected. With inbound relay enabled too, both allow-lists
 apply.
 
+**Reports are checked before they are stored.** The address form is
+predictable, so the report XML is treated as untrusted input: a report is
+accepted only when the domain it claims in `policy_published` is a sending
+domain configured here, and — when it arrived at a per-domain hosted address —
+only when that domain matches the address's `+tag`. Anything else is refused
+and counted in *parse failures* on the DMARC page, so a stranger cannot file
+reports under your domain or push genuine ones out through the retention cap.
+Reports are accepted as gzip, zip, or plain XML.
+
 Parsed report data lives in SQLite and is included in a
 [full backup](#full-backup-and-restore).
 
@@ -844,9 +860,16 @@ sending as that domain. When unset, only level 1 applies for non-privileged
 senders.
 
 **Client IP allow-list (application)** — optional restriction on an
-application: when enabled, list one or more client IPs that may authenticate
-and submit mail as that application. When disabled, any client IP is allowed.
-This is independent of rate limits.
+application: when enabled, list one or more client IPs that may **submit** mail
+as that application; a session from any other address is refused with a 4xx at
+`MAIL FROM`. When disabled, any client IP is allowed. This is independent of
+rate limits, and it takes exact addresses only — CIDR ranges are not parsed.
+
+It is **not an authentication boundary.** The SASL login itself still succeeds;
+the check runs in the journal-milter, on the same fail-open path as level 2
+(below), so if the milter is unavailable the restriction is skipped rather than
+enforced. Use it to narrow where an application may send from, not to contain a
+leaked password — for that, regenerate the password.
 
 **Level 2 — application** — optional override of the domain limit for one
 application (≤ level 1). The ceiling may be **higher or lower** than the domain
@@ -868,7 +891,10 @@ hours and on demand via **Recalculate now**.
 journal-milter and is deliberately fail-open: if the rate-limit lookup hits
 a store error, or the connecting client's IP is not available to the
 milter, level 2 is skipped and the message is accepted rather than held up.
-Level 1 is the backstop that keeps working even when level 2 cannot run.
+The same applies if the milter itself is down — Postfix is configured to
+accept rather than defer when it cannot reach it. Level 1 is the backstop
+that keeps working even when level 2 cannot run, and it is the only one of
+the two that does not depend on the panel process.
 
 ### Deliveries
 

docs/plans/inbound-antispam-panel.md

@@ -125,7 +125,7 @@ New nav item **Inbound spam** (or subsection under **Inbound**) — journal tabl
 with filters (decision, domain, date range), list management on the same page or
 a tab. Mockup: add `docs/assets/panel-ui/inbound_spam.html` in the panel step.
 
-## Schema (migration `0010_inbound_spam_log.sql`)
+## Schema (migration `0011_inbound_spam_log.sql`)
 
 **`inbound_spam_log`**
 
@@ -238,7 +238,7 @@ Target version cut: **`1.10.0`** (MINOR). One commit per step;
 [development.md](../development.md) § Plan checklists.
 
 - [x] Agree journal fields, retention, and RBAC (this plan § Decisions) — **Composer**
-- [ ] Migration `0010_inbound_spam_log.sql` — **Composer**
+- [ ] Migration `0011_inbound_spam_log.sql` — **Composer**
 - [ ] Inbound journal-milter + Postfix wiring — **Composer**
 - [ ] mail.log tailer: inbound reject rows — **Composer**
 - [ ] List CRUD + validation + atomic rspamd map sync — **Composer**

docs/schema-migrations.md

@@ -18,13 +18,14 @@ Documentation.
 
 | Field | Value |
 |---|---|
-| Chain head | `user_version = 9` |
-| Files | `0001_init.sql` … `0009_application_auth_ips.sql` (9 files) |
+| Chain head | `user_version = 10` |
+| Files | `0001_init.sql` … `0010_send_log_app_login_index.sql` (10 files) |
 | Database file | `/data/selfpost.db` (bind mount) |
 | Compatibility | 1.x MINOR releases must boot a `1.0.0` data directory |
 
-Last updated with release **1.9.0** (`0009_application_auth_ips`); **1.9.1**
-had no schema change.
+Last updated in **[Unreleased]** (`0010_send_log_app_login_index`); **1.9.1**
+had no schema change. The release column below records the cut a migration
+shipped in — fill `0010`'s in at the next version cut.
 
 ---
 
@@ -42,6 +43,7 @@ had no schema change.
 0002_sessions.sql          → user_version 2
 …
 0009_application_auth_ips.sql → user_version 9
+0010_send_log_app_login_index.sql → user_version 10
 ```
 
 **Implication:** never delete, rename, or reorder migration files while 1.x must
@@ -63,6 +65,7 @@ replace the embedded set (see [Planned 2.x squash](#planned-2x-squash)).
 | 7 | `0007_rate_limit_auto.sql` | 1.6.0 | DDL | `rate_limits.mode`, `auto_multiplier`, `auto_updated_at` |
 | 8 | `0008_dmarc_reports.sql` | 1.7.0 | DDL | `dmarc_reports`, `dmarc_report_records` |
 | 9 | `0009_application_auth_ips.sql` | 1.9.0 | DDL + data | `applications.auth_ip_restrict`, `auth_allowed_ips`; move legacy app `rate_limits.allowed_ips` into auth columns; clear those IPs on rate limits |
+| 10 | `0010_send_log_app_login_index.sql` | Unreleased | DDL | `idx_send_log_app_login_created_at` — app-scoped rate-limit counts and per-application send statistics were scanning the `created_at` range |
 
 **Kind:** *DDL* — schema only; *data* — `INSERT`/`UPDATE` that must stay correct
 for operators upgrading from older 1.x images.
@@ -117,11 +120,17 @@ code. A 2.x baseline should define `users` directly and omit `admin`.
 
 ### Application trusted IPs (0009)
 
-Before 1.9.0, client IP restriction for an application lived in
-`rate_limits.allowed_ips` (`scope = application`). Migration 0009 copies non-empty
-values into `applications.auth_allowed_ips`, sets `auth_ip_restrict = 1`, and
-clears `rate_limits.allowed_ips` for application scope. Level-2 limits no longer
-carry IP bindings; auth and rate limiting are separate concerns.
+Before 1.9.0, client IPs for an application lived in `rate_limits.allowed_ips`
+(`scope = application`). Migration 0009 copies non-empty values into
+`applications.auth_allowed_ips`, sets `auth_ip_restrict = 1`, and clears
+`rate_limits.allowed_ips` for application scope. Level-2 limits no longer carry
+IP bindings; auth and rate limiting are separate concerns.
+
+Note that the two columns do not mean the same thing: the old list was
+*permissive* (those IPs got the application ceiling, every other IP fell back
+to the domain limit), the new one is *restrictive* (every IP not on the list is
+refused for that application). The conversion branch only fires for a database
+that carried application-scope `allowed_ips` from before 1.9.0.
 
 ### Profile DMARC email (0004 → 0005)