audit 2c: what only the stand could answer, measured and written down

All 2026-10-15; each written beside the code or text it settles.

- A-43: /usr/sbin/postlog is -rwxr-xr-x root:root in the image (postfix
  3.7.11-0+deb12u1; dpkg-statoverride lists postdrop and postqueue only):
  Debian does not install it set-gid, so it is no use to dmarc-ingest
  (cmd/panel/dmarc_ingest.go).
- C-X1: OpenSSL 3.0.22 in the image prints the same public key from
  `x509 -pubkey` and `pkey -pubout` for RSA-2048, P-256, P-384 and a SEC1
  P-256 key - cert-reload's same_pair holds for certbot's ECDSA keys.
- C-K5, D-guide:933/:233: on the live server (Docker 29.6.1, userland
  proxy on 0.0.0.0 and ::, no IPv6 on the network) an outside IPv4 client
  and the host's own public IPv4 address are logged as themselves; the
  host's IPv6 address and 127.0.0.1 arrive as 172.18.0.1. Over IPv6 every
  client is the gateway: one level-1 budget, an application IP list cannot
  name them, rspamd sees the gateway. Guide paragraph under level 1, notes
  at the milter and allow-list, comments at the anvil setup and authip.go,
  and a Security entry in the CHANGELOG (an allow-list naming the gateway
  would admit every IPv6 client).
- D-guide:61: a published port nothing listens on (a throwaway container,
  -p 20999:25) is refused from outside over IPv4 and from the host's public
  IPv4, accepted and closed through 127.0.0.1 - Docker's proxy, which IPv6
  goes through too (not probed over IPv6 for this).
- C-M8: the live installation has received one DMARC report, of one
  record: nothing to set maxReportRecords by yet - said at the constant.
- D-S7, D-arch:516, D-arch:532: a new database filled through the store to
  120 days at 1 900 messages a day (228 000 messages, 1.37 million lines,
  464 MB) on the test server (2 cores): the longest write is the line prune
  after a 30-day gap, 1.9 s for 342 000 lines (0.4 s with nothing to
  delete); the send-log delete 0.6 s; 2 000 lines of a tailer pass 18 ms;
  VACUUM INTO 1.7 s; a second connection writing every 50 ms waited 1.8 s
  at most, no SQLITE_BUSY - inside busy_timeout's 5 s. architecture.md's
  "about a second per million lines" was five times too fast; its "six to
  ten lines of 200 bytes" is 6.0 lines of 146 bytes on the live data.
- D-B16: which favicon is fetched, by the probe server's log: Edge 155
  the SVG, the desktop app's embedded Chromium 152 the PNG, with or
  without sizes="any" - layout.html's "vector wins where supported, raster
  catches the rest" holds; Firefox and Safari not measured.
- D-arch:121: the allow/deny trial again, in rspamd/rspamd:3.11.1-3 with
  today's multimap.conf: every mix of allow and deny entries matching one
  message ended reject; a changed map was used about 10 s later.
- D-sec:424: rspamd runs as _rspamd, uid 11333; the panel is uid 999.

Stand: go vet and go test ./... pass on the server (24 packages); make
e2e exit 0.

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

docs/architecture.md

@@ -144,7 +144,11 @@ smtp/inet` removes Debian's stock smtpd). Outbound delivery still uses the
   deliberately not an `accept` action: with two pre-results rspamd keeps the
   one set first, and deny then won or lost by rule order (seen on rspamd
   3.11, date not recorded). A refusal by the deny list overrides any score,
-  so deny wins whichever entries match. A sender entry is matched against
+  so deny wins whichever entries match - measured in a throwaway
+  `rspamd/rspamd:3.11.1-3` with this file, 2026-10-15: the same address or
+  IP on both lists, an allowed address with a denied domain or IP, and an
+  allowed IP with a denied address were all `reject` (assumptions
+  D-arch:121). A sender entry is matched against
   the envelope sender only (`extract_from = "smtp"`; by default rspamd takes
   a bounce's `From:` header instead - rspamd 3.11.1,
   `src/plugins/lua/multimap.lua`, the `from` callback).
@@ -584,8 +588,12 @@ reads them:
   send-log row carries is deleted (`PruneSendLogLines`), at start and after
   every six-hourly send-log sweep. That removes the lines of rows the sweep
   deleted and the lines that never had a row. The send log is asked once per
-  queue id; the statement still walks the table, about a second per million
-  lines, with the connection taken meanwhile.
+  queue id; the statement still walks the table, with the connection taken
+  meanwhile. Measured on the test server (2 cores, 2026-10-15) with 1.37
+  million lines, 120 days at 1 900 messages a day: 0.4 s when there is
+  nothing to delete, 1.9 s to delete 30 days' lines (342 000) after a gap -
+  under `busy_timeout`'s 5 s, and the longest a second process's write waited
+  meanwhile was 1.8 s (assumptions D-S7, D-arch:516).
 - **Which lines are a row's.** Postfix reuses a queue id once the message has
   left the queue, and a row outlives that by months. `SendLogLines` gives a row
   the lines of its queue id dated from one hour before the row was written to
@@ -599,8 +607,9 @@ reads them:
   catching up at start it writes a line only if the same line is not there.
 - **Not stored:** what the tailer never read — the tail of a file rotated away
   while the panel was down.
-- **Size:** six to ten lines of about 200 bytes per message — more than the row
-  itself. The table is in the database and therefore in a full backup, which
+- **Size:** about six lines of about 150 bytes per message — more than the row
+  itself (the live installation, 2026-10-15: 6.0 lines per queue id, 146 bytes
+  on average, over its first 18 lines; assumptions D-arch:532). The table is in the database and therefore in a full backup, which
   `log/` is not ([security.md](security.md) § Backup and domain export).
 
 **Two one-shot reads** sit beside the follow loop and are unrelated to it, both