inbound-antispam-panel: Filter lists, kind column, matches, note on a sheet

Follows the design commit before it (owner's words quoted there).

The lists' tables are Value, Kind, Matched and Remove. The kind tag
opens the entry's sheet: note, day added, how often it decided a
message in the days the log keeps, and the last match.

Matches are read off the journal on each view, nothing is stored
(inbound.Lists.Usage, store.ListSpamListHits). A row counts for an
entry when the list decided the message - a rejected row whose reply is
the deny rule's message, an accepted row whose verdict carries the
allow rule's symbol for that kind - and the entry fits the row's sender
or client address the way rspamd matches it: an address whole, a domain
as the sender's domain, a network containing the client (an
IPv4-mapped address as IPv4). A failure to count shows the lists with
"never" and logs why.

For that the journal milter keeps the lists' own symbols ahead of its
six-symbol cap: rspamd writes symbols heaviest first, so an allow
entry's -100 came last and was cut behind any six others.

The plan gains "Filter list usage": what counting from the journal
implies, and - the owner asked for it in writing - the conditions under
which a counter kept with each entry becomes worth a migration (the
journal cut by its row cap and not by age; a short retention; counts
that must outlive the journal; a slow page). multimap.conf says which
of its texts SelfPost reads back.

Tests: Usage over every kind on both lists and the rows that are
nobody's; the milter's symbol order; the store query; the page and its
sheets; a handler test from journal rows to the numbers on the page.

Seen: the fixture page with a sheet open, headless Edge at 1360 px -
the same as the accepted drawing.

Checked on the test server, uncommitted tree: go vet ./... ok,
go test ./... ok (22 packages), make e2e ok.

Not seen in a real run: a count above zero. It needs an entry added in
the panel, which I cannot sign in to, and then mail that the list
decides; in particular the deny rule's message arriving in mail.log as
the reply of a milter-reject line is what the trial with rspamc showed,
not yet what Postfix logged.

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

docs/architecture.md

@@ -114,6 +114,13 @@ smtp/inet` removes Debian's stock smtpd). Outbound delivery still uses the
   prefilters rspamd lets the one that ran first decide, and deny then won or
   lost by rule order (seen on rspamd 3.11). A refusal by the deny list
   overrides any score, so deny wins whichever entries match.
+  How often an entry decided a message is not stored: `Lists.Usage` reads it
+  off the journal on each view of Filter lists - the rows a list decided (the
+  deny rule's reply, the allow rule's symbol, which the journal milter keeps
+  ahead of its six-symbol cap) matched against the entries as rspamd matches
+  them. When that stops being good enough is written in
+  [plans/inbound-antispam-panel.md](plans/inbound-antispam-panel.md) § Filter
+  list usage.
   **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`,

docs/guide.md

@@ -876,7 +876,13 @@ anyone on the host; they hold addresses, not secrets.
 In the panel the lists are **Inbound › Filter lists** (global role), and what
 port 25 decided about each message is **Inbound › Log**: accepted mail with the
 filter's verdict, refused mail with the reply it was given. A row of the log
-leads to the lists with its sender filled in. A user with the *domain* role
+leads to the lists with its sender filled in. Beside each entry of a list is
+how often it decided a message, counted from the log - so over the days the
+log keeps - and *never* marks an entry that may have outlived its use. The
+count depends on two things in
+[multimap.conf](../deploy/antispam/rspamd/multimap.conf): the message of the
+deny rules and the names of the allow symbols; change them and every entry
+reads *never*. A user with the *domain* role
 sees the log of the inbound domains assigned to them, and not the lists. How
 long the log keeps a row is set under **Server › Settings**.
 

docs/plans/inbound-antispam-panel.md

@@ -97,8 +97,9 @@ changes to it: the sender column is headed *From*; *Why* is not a column but
 a sheet over the page, opened by the decision tag, holding a centred table of
 who decided, the verdict and symbols or the reply, and the subject whole
 (kept on the sheet at his word: the table clips it); a message Postfix itself
-refused offers no *Deny sender*. Inbound › Filter lists is built and not yet
-accepted.
+refused offers no *Deny sender*. Inbound › Filter lists was redrawn at his word
+the same day - kind in a column of its own, the note on the entry's sheet,
+matches counted (§ Filter list usage) - and awaits his look at the result.
 
 ### Retention
 
@@ -126,6 +127,46 @@ Mirror send-log retention:
 List change → atomic map rewrite (same pattern as Postfix maps). No reload:
 rspamd rereads a changed map file by itself (about ten seconds on 3.11).
 
+### Filter list usage (owner, 2026-10-12)
+
+Each entry shows how often it decided a message (*Matched*, or *never*) and,
+on its sheet, when it last did - so that entries nothing matches any more can
+be removed. **The count is read off the journal on every view of the page;
+nothing is stored for it.** A journal row counts for an entry when the list
+decided the message - a rejected row whose reply is the deny rule's message,
+an accepted row whose verdict carries the allow rule's symbol
+(`SELFPOST_ALLOW_IP` / `_FROM` / `_DOMAIN`, which the journal milter always
+keeps) - and the entry fits the row's sender or client address the way rspamd
+matches it (`inbound.Lists.Usage`).
+
+What follows from counting this way, and is accepted:
+
+- the count reaches back as far as the journal does: its retention (90 days by
+  default), which is what the sheet says;
+- a row counts for every fitting entry of the deciding list, since the journal
+  does not say which of two the filter met first;
+- a message refused at end-of-message is one row whatever its recipient count,
+  so a count is of messages, roughly.
+
+**When to move to a counter kept with each entry** (a migration adding hits
+and last-hit to `inbound_spam_list`, bumped where the journal row is written;
+the owner asked for the condition to be written down). Any one of:
+
+1. **The journal is cut by its 10 000-row cap and not by age.** Then it holds
+   fewer days than its retention, the sheet's "in the last 90 days" is no
+   longer true, and *never* stops being evidence that an entry is stale. The
+   sign: the log tailer's prune line keeps reporting rows removed while the
+   oldest row of Inbound › Log is younger than the retention.
+2. **The retention is set short** (towards its minimum of 7 days) for reasons
+   of its own, privacy or disk. A week without a match does not make an entry
+   stale.
+3. **Counts are wanted that outlive the journal** - since the entry was added.
+4. **The page is slow.** A view reads every journal row a list decided and
+   tries it against every entry. With the cap that is at most 10 000 rows
+   times the number of entries; past a few hundred entries, measure it.
+
+Until then no migration is spent on it.
+
 ### Activation
 
 | Condition | Behaviour |