release: 2.5.2: audit stage 2c - what SelfPost relies on, read in the sources

The owner's word, 2026-10-15: "Да, режем."

Every place SelfPost relies on another program was read in that program's
source, of the version the image runs, and is cited in the code (621
entries, docs/assumptions-2026-10-14.md); what the sources contradicted is
fixed: rspamd signing a sender's own verdict, the sender map's first key,
queue expiry and Postfix's time values, refusal and recipient lines as
Postfix writes them, the rotated log read until postlogd lets it go,
inbound mail over 10 MB, local delivery to an address literal, supervision
(Postfix stopped, give-ups FATAL, the reload's exit read), sasldb2 through
a copy, Health dialling sockets and showing the certificate Postfix
serves, Referrer-Policy same-origin, migrations under BEGIN IMMEDIATE,
certbot's links followed, about forty sentences of the documents, and ten
measurements on the stand. The sender check reads From: with OpenDKIM's
own parser, ported and checked against the C and against OpenDKIM's
signing; L8 is closed; an address OpenDKIM would cut short is refused.
Plus the findings of both reviews of the stage (9eddd49).

Rolled out to the test server as 2.5.1-post.9eddd49 (the same code): no
migration, schema 9; all programs RUNNING, the container healthy,
Postfix with its three milters, nothing in the logs.

CHANGELOG cut; pin 2.5.2 in deploy/docker-compose.yml, README, guide (and
its sample restore message); development.md "from pin"; roadmap row and
recommended order; stage 2c marked shipped in the plan. No tag.

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

docs/audit-2026-10-12.md

@@ -840,7 +840,7 @@ order - each stands on the one before.
    refusal's line and a recovered row), guide § Outbound log and § Health,
    schema-migrations.md for the mark on `sender_check_days`. — **Sonnet**
 
-### Stage 2c — the sender check reads From: as OpenDKIM does → `2.5.2`
+### Stage 2c — the sender check reads From: as OpenDKIM does → `2.5.2` (shipped 2026-10-15)
 
 Decided by the owner on 2026-10-14, after reading OpenDKIM's source together
 (libopendkim `dkim_mail_parse`, called in `mlfi_eoh` on the first `From:`

docs/development.md

@@ -107,7 +107,7 @@ than the default «meaningful step» rule in [§ Commits and release build](#com
 2. Git tag `vX.Y.Z` and publish the GitHub Release only on explicit request (see
    [§ Release image](#release-image)).
 
-**Planned version cuts** (from pin `2.5.1`; adjust if semver changes mid-track):
+**Planned version cuts** (from pin `2.5.2`; adjust if semver changes mid-track):
 
 | Stage | ID | Cut |
 |---|---|---|

docs/guide.md

@@ -190,14 +190,14 @@ cat ./data/setup-token
 #### Fixed image tag
 
 `deploy/docker-compose.yml` pins an explicit version (`ghcr.io/mixeme/selfpost:X.Y.Z`),
-deliberately never `:latest`. The current pin is `2.5.1`. **No 2.x image is
+deliberately never `:latest`. The current pin is `2.5.2`. **No 2.x image is
 published on ghcr.io yet** (the newest there is `1.3.0`); until one is, build
 it from the checkout under the pinned name, and Compose uses the local image
 instead of pulling:
 
 ```sh
-docker build -f build/Dockerfile --build-arg VERSION=2.5.1 \
-  -t ghcr.io/mixeme/selfpost:2.5.1 .
+docker build -f build/Dockerfile --build-arg VERSION=2.5.2 \
+  -t ghcr.io/mixeme/selfpost:2.5.2 .
 ```
 
 `VERSION` must equal the tag: it is the version the backup check compares
@@ -849,7 +849,7 @@ A version mismatch at step 5 refuses to start and leaves `/data` untouched —
 the panel exits with a message naming the tag to use, e.g.:
 
 ```
-backup: this backup was created by SelfPost 2.5.0 but this image is 2.5.1 — restore into the matching image (selfpost:2.5.0)
+backup: this backup was created by SelfPost 2.5.1 but this image is 2.5.2 — restore into the matching image (selfpost:2.5.1)
 ```
 
 Fix the tag in `docker-compose.yml` (build that tag as under [Fixed image

docs/roadmap.md

@@ -42,7 +42,7 @@ in `git log` and [CHANGELOG.md](../CHANGELOG.md).
 | from-header-binding | Hold a message's `From:` header against the application that sends it | shipped `2.4.0` | 9/9 | [plans/from-header-binding.md](plans/from-header-binding.md) |
 | panel-redesign | Panel redesign (accepted mockups, design contract) | shipped `2.0.0` | 27/27 | [plans/panel-redesign.md](plans/panel-redesign.md) |
 | schema-squash | Squash SQLite migrations into a 2.x baseline | built in panel-redesign (stage 1) | — | [plans/panel-redesign.md](plans/panel-redesign.md) |
-| audit-2026-10-12 | Follow-ups of the 2026-10-12 full-tree code audit, seven stages | in progress (stage 0 shipped `2.4.2`, stages 1+2 `2.5.0`, 2b `2.5.1`; next stage 2c → `2.5.2`) | 49/81 | [audit-2026-10-12.md](audit-2026-10-12.md) |
+| audit-2026-10-12 | Follow-ups of the 2026-10-12 full-tree code audit, seven stages | in progress (stage 0 shipped `2.4.2`, stages 1+2 `2.5.0`, 2b `2.5.1`, 2c `2.5.2`; next stage 3 → `2.5.3`) | 49/81 | [audit-2026-10-12.md](audit-2026-10-12.md) |
 
 **Recommended order** (not binding; owner, 2026-10-09: feature order follows
 development convenience): **panel-redesign** shipped as `2.0.0` (2026-10-11) and
@@ -51,7 +51,8 @@ kit — styling its two screens once instead of twice. **delivery-log-storage**
 shipped as `2.2.0` the same day, **panel-notifications** as `2.3.0` and
 **from-header-binding** as `2.4.0`. Stage 0 of
 [audit-2026-10-12](audit-2026-10-12.md) shipped as `2.4.2` (2026-10-14), its
-stages 1 and 2 as `2.5.0` the same day, and stage 2b as `2.5.1`.
+stages 1 and 2 as `2.5.0` the same day, stage 2b as `2.5.1`, and stage 2c as
+`2.5.2` (2026-10-15).
 Nothing is agreed after it: every remaining
 item is a candidate. panel-docs shipped in
 [CHANGELOG.md](../CHANGELOG.md) `[1.8.0]`; dmarc-reports in `[1.7.0]`