@bobfrankston/rmfmail 1.2.309 → 1.2.312

package/.commitmsg

@@ -1,11 +1,39 @@
-Trust banner names the intermediary and the action that trusts it
-
-"Is there a 'trust this intermediary' operation or do I need to edit it
-manually? If so the banner should tell which and how" (Bob 2026-09-08). The
-button existed since v1.2.308 but the finding text did not mention it. The
-spam-verdict note now ends with: Sent on the author's behalf by google.com,
-which signed it; "Trust google.com as an intermediary" stops this note for
-mail google.com signs. The redirector warning ends the same way, naming the
-signer — or, when nobody signed for the redirector host, says plainly that
-there is no intermediary to trust and only the sender could vouch for the
-link. mailx-types 0.1.85.
+Trusted mailing lists: "how do I say that this is a valid mailing list message"
+
+Bob 2026-09-09, on an IEEE-CS meeting announcement through MIT's Mailman.
+The list keeps the poster's own From (gmail.com publishes no DMARC policy,
+so Mailman does not rewrite it), re-sends from its own host with its own
+bounce address, and tags the subject and appends a footer — which breaks
+the gmail.com and mitprod signatures. iecc.com recorded both as dkim=fail,
+SpamAssassin fired POSSIBLE_GMAIL_PHISHER / FREEMAIL_FORGED_FROMDOMAIN /
+DKIM_ADSP_CUSTOM_MED, and the chip went red on a talk announcement. The
+author can never be proved on list mail, so per-sender trust had nothing
+to hold on to and the banner (correctly) offered no button.
+
+The LIST is proved: spf=pass for the mit.edu bounce address, the same host
+as Sender:. New allowlist.jsonc `trustedLists`, keyed on List-Id — the one
+header identical on every post whoever wrote it. An entry counts only on a
+message the topmost Authentication-Results proves the list host sent
+(spf=pass for the Sender:/bounce domain, or dkim=pass for the list domain,
+which ISOC's Mailman adds). On a proved list, trusted or not, the author's
+DKIM failure and the From-vs-path rules (LIST_RELAY_RULES in trust.ts) are
+set aside as the list's doing; trusted + proved silences the verdict and
+hides the chip, exactly as a trusted intermediary does. SPF and DMARC
+failures and URL/phishing listings are never silenced — a list member can
+post a bad link like anyone else.
+
+Actions: "Trust the ‹List-Id› list" under a spam-verdict banner; "Trust
+the ‹List-Id› mailing list" in the From address's right-click menu, which
+the chip's tooltip now points to (an unflagged post shows only the chip).
+trustSenderOrDomain gains type "list"; TRUST_LIST_KEYS in mailx-types is
+now the single table mapping trust type → allowlist key for the desktop
+service and the Android web-service, which each carried their own ternary.
+Android web-settings DEFAULT_ALLOWLIST gains trustedLists.
+
+Tests: IEEE-CS headers verbatim (chip kind no longer forgery; trusted hides
+it; flagged variant cautions naming the list and the action, then goes
+quiet), ISOC (DKIM-proved list), an unproved List-Id (just a header), a
+phish listing and an SPF failure on a trusted list (never silenced).
+mailx-types 0.1.89, mailx-settings 0.1.82, mailx-store 0.1.119,
+mailx-service 0.1.35, mailx-store-web 0.1.111. docs/allowlist.md and
+docs/spam-false-positives.md updated; TODO C165.

package/.llm/trusted-lists.md

@@ -0,0 +1,46 @@
+# Trusted mailing lists (session note, Claude Code 2026-09-09)
+
+Bob: "how do i say that this is a valid mailing list message" → "implement it".
+
+## Problem
+IEEE-CS list (MIT Mailman, List-Id ieee-cs.mit.edu) leaves the poster's own From
+(petmager@gmail.com; gmail has no DMARC policy so no From rewrite). Mailman's subject tag
++ footer break both DKIM signatures (gmail.com, mitprod.onmicrosoft.com) → iecc records
+dkim=fail; SA fires POSSIBLE_GMAIL_PHISHER, FREEMAIL_FORGED_FROMDOMAIN etc. → mailx kind
+"forgery", red chip; sender is unproved so no trust button and an allowlist sender entry is
+ignored by design. Only stable, verifiable identity = the LIST: spf=pass for the mit.edu
+bounce address (Sender:/Return-Path) + List-Id.
+
+## Design
+- allowlist.jsonc `trustedLists: string[]` keyed on List-Id value (e.g. "ieee-cs.mit.edu").
+- trust.ts: listProof(input) → { id, proved, host }. Proof = topmost Authentication-Results
+  has spf=pass whose mailfrom domain is sameOrg with Sender: domain or the List-Id, OR
+  dkim=pass header.d sameOrg with either. List alone proves nothing.
+- On a PROVED list (trusted or not): author-side DKIM failure is the list's doing → dropped
+  from authFailures (SPF/DMARC failures stay vetoes); LIST_RELAY_RULES (rules that test the
+  From domain against the transport, which a list breaks by design: POSSIBLE_GMAIL_PHISHER,
+  FREEMAIL_FORGED_FROMDOMAIN, DKIM_ADSP_*, NML_ADSP_*, FORGED_<provider>_RCVD) → neutral.
+  URL/phish listings stay forgery.
+- Trusted + proved list → server-spam-verdict silenced + chip hidden (same as intermediary),
+  unless kind is still forgery / SPF or DMARC failed.
+- Proved, untrusted → caution note names the list and the button; finding.list = List-Id;
+  SpamScore.listId/listProved/listTrusted for the chip + From-address context menu item.
+- IPC: trustSenderOrDomain(type "list") → trustedLists. Files: mailx-service/index.ts,
+  web-service.ts (android), api-client.ts type, viewer buttons. jsonrpc/mailxapi/bootstrap
+  pass `type` through untouched.
+- Tests: tests/trust.test.ts with the IEEE-CS headers verbatim (trimmed).
+
+## Files to touch
+packages/mailx-types/trust.ts (+bump), mailx-settings/index.ts DEFAULT_ALLOWLIST (+bump),
+mailx-store/store.ts trustInput (+bump), mailx-service/index.ts (+bump), mailx-store-web
+web-service.ts + web-settings.ts DEFAULT_ALLOWLIST (+bump), client/lib/api-client.ts,
+client/components/message-viewer.ts, docs/allowlist.md (+ mailx-settings/docs copy),
+tests/trust.test.ts, .commitmsg, TODO.md C165, root version 1.2.311. Then rebuild.cmd.
+
+## Status
+- [x] trust.ts
+- [x] settings/store/service/web
+- [x] client (banner button, From-menu item, chip tooltip)
+- [x] tests pass (tests/trust.test.ts 40/40)
+- [x] docs/TODO/.commitmsg/versions (v1.2.311)
+- [ ] rebuild.cmd — running next; app must be restarted to pick up the new bundle

package/TODO.md

@@ -144,7 +144,7 @@ None of these are truly showstoppers — mailx is usable — but they're the nex
 
 | # | Status | Item |
 |---|---|---|
-| **C165** | PARTIAL | Spam banner fires on subscribed newsletters (Constant Contact / Adobe / Mokin). **Rule classification + DMARC veto shipped v1.2.286** — severity now comes from what the `tests=` rules test, not from the score; red is reserved for forgery. **Still owed: sender trust** via `allowlist.jsonc` + an inline trust action on the banner. **Do not tune the `threshold/2` chip floor.** [`docs/spam-false-positives.md`](spam-false-positives.md). [S] |
+| **C165** | PARTIAL | Spam banner fires on subscribed newsletters (Constant Contact / Adobe / Mokin). **Rule classification + DMARC veto shipped v1.2.286** — severity now comes from what the `tests=` rules test, not from the score; red is reserved for forgery. **Still owed: sender trust** via `allowlist.jsonc` + an inline trust action on the banner. **Do not tune the `threshold/2` chip floor.** **Trusted mailing lists shipped v1.2.311** (`trustedLists` by List-Id, proof = server SPF/DKIM pass for the list host). [`docs/spam-false-positives.md`](spam-false-positives.md). [S] |
 | [**S56**](#ext56) | OPEN | Row-objects own the preview pane — the last open slice of the old "S1 local-first refactor" umbrella. All S1 sub-shipments (tombstones, opaque UUIDs, stable row UUID, Message-ID move-detection, pink rows, viewer-reacts-to-list-replace, unified-inbox pink) are in Done under their version tags; this is what remains. ✓ (can start the `focus()`/`unfocus()` seam; full migration is more than one session) |
 | [**S9**](#ext9) | PARTIAL | Predownloading gaps — 60s prefetch landed v1.0.321; per-account prefetch guard already in mailx-imap (`prefetchingAccounts` Set). Remaining: batch body prefetch (C24) for 10–50× speedup. |
 | [**S51**](#ext51) ❓ | PARTIAL | Calendar Thunderbird-style sidebar. Sidebar UI + visible-by-default + 4-column grid reflow shipped v1.0.375/376. **Still owed**: Google Calendar live fetch via service-side proxy. Open Q: keep the full-screen calendar modal, or retire in favor of sidebar-only? |
@@ -230,7 +230,7 @@ Items blocked on a design decision. Short-form question here; full context in th
 | **C129** | OPEN | **Android prod/dev split via filename/URL channel** — User 2026-05-09 (revised): no separate MAUI project. Same source tree builds; output filenames distinguish channels: Phase 1 (start now) writes `rmfmaildev.apk` alongside today's `mailx-maui.apk`. Phase 2 (when a release is declared) switches to `rmfmail-<version>.apk` versioned + `rmfmaildev.apk` for latest, with promotion = re-pointing `rmfmail.apk` at a chosen version. Single APK contents per build; channel is runtime setting in AppUpdater (Settings toggle for which URL to poll). Side-by-side install on one device NOT supported by this design (single Android package id) — that's a separate need. See `docs/prod-android.md` for full plan. Phase 1 ~30 min; full flow ~2.5 hours when activated. |
 | **C130** | OPEN | **Reset prefetch error budget after fresh sync** — Android: `errors`/`failedThisSession` accumulate within a prefetch session. Already resets on next syncAll cycle (since each `prefetchBodies(account)` call is fresh). Verify this works in practice via logit; if a long sync session burns through budget and stays stuck, add an explicit reset on `bodyAvailable` events that fire while prefetch is still running. |
 | **C164** | RESEARCHED | **Thundermail / JMAP provider** — full protocol survey at [`docs/thundermail-jmap.md`](thundermail-jmap.md), probed live 2026-08-17. Thundermail is Stalwart, so there is no proprietary API: IMAP 993 / SMTP 465 work **today with zero code** (an `accounts.jsonc` entry and nothing else), CardDAV `/dav/card` + CalDAV `/dav/cal` are http-basic, and JMAP is live at `https://mail.thundermail.com/jmap/` advertising core / mail / submission / calendars / contacts / filenode / sieve / quota plus **WebSocket push** (`supportsPush: true`). JMAP is the attractive bet: it kills the IDLE lane, the 5-lane connection semaphore and the Dovecot 20-conn ceiling, needs no transport injection (one path for Android and desktop, cf. C125), and `Email/changes` is native set-difference sync. **From address: resolved — good.** The 15-alias cap is `@thundermail.com`/`@tb.pro` only; custom domains get unlimited aliases plus a catch-all (empty-name alias), and with catch-all on you can send from any prefix unregistered — their own example is the per-vendor pattern already used on `bob.ma`. mailx needs ~nothing here (per-message From identity shipped v1.2.201); only Stalwart-side `MAIL FROM`/DKIM validation for an unregistered prefix is untested. **Still blocking/staged:** JMAP-calendars and `filenode` are unratified drafts; OAuth `scopes_supported` covers mail only (no calendars/contacts scope); invite-only beta so there is nothing to test against; and **no Drive equivalent** — Thunderbird Send is one-shot file *sharing*, not a listable revisable store, so mailx's shared-config dependency (`accounts.jsonc` / `contacts.jsonc` / preferences / allowlist on GDrive) has no home. **C161 is therefore the prerequisite, not JMAP** — the `_rmfmail` hidden-IMAP-folder state channel removes the Drive dependency for every account type at once and keeps working unchanged if JMAP lands later. Until C161 ships, adopting Thundermail is a half-migration that trades a Google dependency for a Thunderbird one. |
-| **C165** | PARTIAL | **Spam-banner false positives — trust the sender, do not tune the threshold** — full diagnosis and a "What shipped" section at [`docs/spam-false-positives.md`](spam-false-positives.md). Bob 2026-08-27: the red "This message is not what it says it is" banner fired on Constant Contact / Adobe MAX / Mokin newsletters he subscribed to, because `serverSpamVerdict()` consumed SpamAssassin’s **bottom line** (a delivery decision) to answer a different question (is this forged) and never parsed the `tests=` list in the same header. **Shipped v1.2.286–289:** `tests=` is classified into forgery / association / bulk / neutral / other; `X-Spam-Report` supplies each rule’s score and description so findings name their evidence; the **topmost** `Authentication-Results` is read for a DMARC-aligned pass with `header.from=` checked against the real From. Severity follows the rules — danger only on a forgery rule or a server-recorded SPF/DKIM/DMARC failure (phishing/malware URL listings count); a new neutral `info` severity (no headline, no "do not open" footer, grey chip) when the sender is proved and every scoring rule is classifiable, or the score is all bulk; caution otherwise, **including a proved sender whose rules are unclassified** — unknown is never a reason to go quiet (326 messages in the store). `spamScoreOf()` and the banner now come from one analysis so they cannot disagree. Measured over 20,291 messages: of 1,131 flagged, 294 stay red, 672 caution, 165 quiet; the 2026-08-25 phishes stay red. Tests: all four samples verbatim + both ways the DMARC proof could be gamed. Follow-up v1.2.288: proof of the From line accepts `DKIM_VALID_AU` and `ALL_TRUSTED` as well as DMARC (`provedBy` names which, in banner and chip tooltip) — Bob's OWN mail carries no `Authentication-Results` at all and was getting a caution banner over a URL it quoted. **John Levine 2026-08-27 confirms the direction:** DCC means bulk, "you have to whitelist the senders … I haven't tried to do a global one because everyone's different" — bulk is a fact about the mail, wanted is a fact about the reader. Server-side whitelisting is out for Bob (he whitelists `@bob.ma` and "that gets abused"), so the client list must key on evidence (DKIM-verified domain, Delivered-To tag), not the From line. **Still owed:** sender trust — `allowlist.jsonc` already is the approved-sender store (`getAllowlist()` at `mailx-service/index.ts:1980`) and the viewer already has “Trust all senders at ‹domain›”, but nothing consults it when computing `trust`/`spamScore` (`store.ts:586`) and the banner has no inline trust action. Open Qs unchanged: trust key granularity (shared ESP domain vs Reply-To org vs Delivered-To tag), whether trust suppresses the whole banner or only the bulk/association half (leaning: never suppress forgery evidence), and auto-trust on reply/move-out-of-Junk. |
+| **C165** | PARTIAL | **Spam-banner false positives — trust the sender, do not tune the threshold** — full diagnosis and a "What shipped" section at [`docs/spam-false-positives.md`](spam-false-positives.md). Bob 2026-08-27: the red "This message is not what it says it is" banner fired on Constant Contact / Adobe MAX / Mokin newsletters he subscribed to, because `serverSpamVerdict()` consumed SpamAssassin’s **bottom line** (a delivery decision) to answer a different question (is this forged) and never parsed the `tests=` list in the same header. **Shipped v1.2.286–289:** `tests=` is classified into forgery / association / bulk / neutral / other; `X-Spam-Report` supplies each rule’s score and description so findings name their evidence; the **topmost** `Authentication-Results` is read for a DMARC-aligned pass with `header.from=` checked against the real From. Severity follows the rules — danger only on a forgery rule or a server-recorded SPF/DKIM/DMARC failure (phishing/malware URL listings count); a new neutral `info` severity (no headline, no "do not open" footer, grey chip) when the sender is proved and every scoring rule is classifiable, or the score is all bulk; caution otherwise, **including a proved sender whose rules are unclassified** — unknown is never a reason to go quiet (326 messages in the store). `spamScoreOf()` and the banner now come from one analysis so they cannot disagree. Measured over 20,291 messages: of 1,131 flagged, 294 stay red, 672 caution, 165 quiet; the 2026-08-25 phishes stay red. Tests: all four samples verbatim + both ways the DMARC proof could be gamed. Follow-up v1.2.288: proof of the From line accepts `DKIM_VALID_AU` and `ALL_TRUSTED` as well as DMARC (`provedBy` names which, in banner and chip tooltip) — Bob's OWN mail carries no `Authentication-Results` at all and was getting a caution banner over a URL it quoted. **John Levine 2026-08-27 confirms the direction:** DCC means bulk, "you have to whitelist the senders … I haven't tried to do a global one because everyone's different" — bulk is a fact about the mail, wanted is a fact about the reader. Server-side whitelisting is out for Bob (he whitelists `@bob.ma` and "that gets abused"), so the client list must key on evidence (DKIM-verified domain, Delivered-To tag), not the From line. **Still owed:** sender trust — `allowlist.jsonc` already is the approved-sender store (`getAllowlist()` at `mailx-service/index.ts:1980`) and the viewer already has “Trust all senders at ‹domain›”, but nothing consults it when computing `trust`/`spamScore` (`store.ts:586`) and the banner has no inline trust action. Open Qs unchanged: trust key granularity (shared ESP domain vs Reply-To org vs Delivered-To tag), whether trust suppresses the whole banner or only the bulk/association half (leaning: never suppress forgery evidence), and auto-trust on reply/move-out-of-Junk. **v1.2.311 — trusted mailing lists.** Bob 2026-09-09, on an IEEE-CS announcement (MIT Mailman, poster's own gmail.com From kept, both signatures broken by the subject tag + footer, `POSSIBLE_GMAIL_PHISHER` + `dkim=fail` → red chip, author unprovable so no trust button by design): "how do I say that this is a valid mailing list message". New `allowlist.jsonc` `trustedLists` keyed on **List-Id**; counts only when the topmost `Authentication-Results` proves the list host (`spf=pass` for the Sender:/bounce domain, or `dkim=pass` for the list domain). On a proved list the author's DKIM failure and the From-vs-path rules (`LIST_RELAY_RULES` in trust.ts) are set aside as the list's doing; trusted + proved silences the verdict and the chip; SPF/DMARC failures and URL/phish listings never. Buttons: "Trust the ‹List-Id› list" on the banner, "Trust the ‹List-Id› mailing list" in the From address menu (chip tooltip points there). `TRUST_LIST_KEYS` in mailx-types is now the one table mapping trust type → allowlist key for desktop and Android. Tests: IEEE-CS headers verbatim + ISOC (DKIM-proved list) + unproved List-Id + phish listing + SPF fail. |
 
 <a id="concerns"></a>
 

package/client/android-bootstrap.bundle.js

@@ -2233,7 +2233,12 @@ function sameOrg(a, b) {
     return false;
   return x === y || x.endsWith("." + y) || y.endsWith("." + x);
 }
-function classifyRule(name, dmarcFailed) {
+function classifyRule(name, dmarcFailed, listRelayed = false) {
+  if (listRelayed) {
+    for (const re of LIST_RELAY_RULES)
+      if (re.test(name))
+        return "neutral";
+  }
   if (dmarcFailed && name === "DKIM_INVALID")
     return "forgery";
   for (const re of FORGERY_RULES)
@@ -2275,6 +2280,32 @@ function provedIntermediary(input) {
       return entry;
   return "";
 }
+function listProof(input) {
+  const none = { id: "", proved: false, host: "" };
+  const raw = header(input.headerLines, "list-id");
+  if (!raw)
+    return none;
+  const id = (raw.match(/<([^>]+)>/)?.[1] || raw).trim().toLowerCase();
+  if (!id)
+    return none;
+  const senderDomain = (bare(header(input.headerLines, "sender")).split("@")[1] || "").toLowerCase();
+  const hosts = [senderDomain, id].filter(Boolean);
+  const auth = headerAll(input.headerLines, "authentication-results")[0] || "";
+  for (const part of auth.split(";")) {
+    if (/\bspf=pass\b/i.test(part)) {
+      const mailfrom = (part.match(/(?:spf|smtp)\.mailfrom=([^\s;,]+)/i)?.[1] || "").toLowerCase();
+      const domain = mailfrom.includes("@") ? mailfrom.split("@")[1] : mailfrom;
+      if (domain && hosts.some((h) => sameOrg(domain, h)))
+        return { id, proved: true, host: domain };
+    }
+    if (/\bdkim=pass\b/i.test(part)) {
+      const d = (part.match(/header\.d=([^\s;,]+)/i)?.[1] || "").toLowerCase();
+      if (d && hosts.some((h) => sameOrg(d, h)))
+        return { id, proved: true, host: d };
+    }
+  }
+  return { id, proved: false, host: "" };
+}
 function dmarcProof(input) {
   const auth = headerAll(input.headerLines, "authentication-results")[0] || "";
   if (!auth)
@@ -2327,6 +2358,10 @@ function analyzeServerSpam(input) {
   const threshold = Number(status.match(/required=(-?[\d.]+)/)?.[1]);
   const flagged = /^yes/i.test(status) || /^yes/i.test(flag);
   const dmarc = dmarcProof(input);
+  const listFound = listProof(input);
+  const trustedLists = (input.trustedLists || []).map((l) => (l || "").trim().toLowerCase());
+  const list = { ...listFound, trusted: listFound.proved && trustedLists.includes(listFound.id) };
+  const authFailures = list.proved && !dmarc.failed ? dmarc.authFailures.filter((f) => f !== "DKIM") : dmarc.authFailures;
   const report = parseSpamReport(header(input.headerLines, "x-spam-report"));
   const names = (status.match(/tests=([\s\S]*?)(?=\s+[a-z_]+=|$)/)?.[1] || "").replace(/\s+/g, "").split(",").map((n) => n.toUpperCase()).filter(Boolean);
   const rules = names.map((name) => {
@@ -2335,7 +2370,7 @@ function analyzeServerSpam(input) {
       name,
       score: found ? found.score : NaN,
       description: found ? found.description : "",
-      cls: classifyRule(name, dmarc.failed)
+      cls: classifyRule(name, dmarc.failed, list.proved)
     };
   });
   const scored = (r) => !(r.score <= 0);
@@ -2344,7 +2379,7 @@ function analyzeServerSpam(input) {
   const unknownWeight = unknown.reduce((sum, r) => sum + r.score, 0);
   const unknownCouldFlagAlone = !unknown.length ? false : !Number.isFinite(unknownWeight) || !Number.isFinite(threshold) ? true : unknownWeight >= threshold;
   const bulkOnly = rules.every((r) => !scored(r) || r.cls === "bulk" || r.cls === "neutral");
-  const kind = dmarc.authFailures.length || present("forgery") ? "forgery" : present("association") ? "association" : unknownCouldFlagAlone ? "unclassified" : rules.length ? "bulk" : "unclassified";
+  const kind = authFailures.length || present("forgery") ? "forgery" : present("association") ? "association" : unknownCouldFlagAlone ? "unclassified" : rules.length ? "bulk" : "unclassified";
   const has = (name) => rules.some((r) => r.name === name);
   const provedBy = dmarc.pass ? "dmarc" : has("DKIM_VALID_AU") ? "dkim" : has("ALL_TRUSTED") ? "trusted" : "";
   const fromDomain = (bare(input.fromAddress).split("@")[1] || "").toLowerCase();
@@ -2364,10 +2399,11 @@ function analyzeServerSpam(input) {
     provedDomain: dmarc.domain || fromDomain,
     provedPolicy: dmarc.policy,
     bayesHam: rules.some((r) => r.name === "BAYES_00" || r.name === "BAYES_01"),
-    authFailures: dmarc.authFailures,
+    authFailures,
     reasons,
     intermediary: provedIntermediary(input),
-    signers: dkimSigners(input)
+    signers: dkimSigners(input),
+    list
   };
 }
 function provedNote(a) {
@@ -2386,13 +2422,15 @@ function serverSpamVerdict(input) {
   const a = analyzeServerSpam(input);
   if (!a || !a.flagged)
     return null;
-  const trustedAndProved = input.senderTrusted && a.proved || !!a.intermediary;
+  const trustedAndProved = input.senderTrusted && a.proved || !!a.intermediary || a.list.trusted;
   if (trustedAndProved && a.kind !== "forgery" && !a.authFailures.length)
     return null;
   const senderDomain = (bare(header(input.headerLines, "sender")).split("@")[1] || "").toLowerCase();
   const relay = senderDomain ? a.signers.find((s) => sameOrg(s, senderDomain)) : "";
   const via = relay && !a.proved ? { via: relay } : {};
   const relayNote = relay && !a.proved ? `. Sent on the author's behalf by ${relay}, which signed it; "Trust ${relay} as an intermediary" stops this note for mail ${relay} signs.` : "";
+  const listNote = a.list.proved && !a.list.trusted && !a.proved ? `. Delivered by the ${a.list.id} mailing list \u2014 ${a.list.host} proved it sent this \u2014 which re-sent the author's message from its own host, so nothing proves the From line; "Trust the ${a.list.id} list" stops this note for mail the list delivers.` : "";
+  const viaList = listNote ? { list: a.list.id } : {};
   const numbers = Number.isFinite(a.score) && Number.isFinite(a.threshold) ? `SpamAssassin score ${a.score} of ${a.threshold}` : "flagged by SpamAssassin";
   const why = a.reasons.length ? ` \u2014 ${a.reasons.join("; ")}` : "";
   const bayes = a.bayesHam ? "; your own trained filter puts it at 0-1% spam (BAYES_00)" : "";
@@ -2423,14 +2461,16 @@ function serverSpamVerdict(input) {
       id: "server-spam-verdict",
       severity: "caution",
       text: "This claims to be a sender you trust, but nothing proves it is.",
-      detail: `No DMARC pass, no valid signature from the sending domain, and it passed through hosts your server does not trust. ${numbers}${why}`
+      detail: `No DMARC pass, no valid signature from the sending domain, and it passed through hosts your server does not trust. ${numbers}${why}${listNote}`,
+      ...viaList
     };
   return {
     id: "server-spam-verdict",
     severity: "caution",
     text: "Your mail server classified this as spam before delivering it.",
-    detail: `${proof}${numbers}${why}${bayes}${relayNote}`,
-    ...via
+    detail: `${proof}${numbers}${why}${bayes}${relayNote}${listNote}`,
+    ...via,
+    ...viaList
   };
 }
 function selfSpoof(input) {
@@ -2533,6 +2573,8 @@ function redirectorLink(input) {
         continue;
       if (sameOrg(target.hostname, url.hostname))
         continue;
+      if (senderDomain && sameOrg(target.hostname, senderDomain))
+        continue;
       const signer = signers.find((s) => sameOrg(s, url.hostname));
       const how = signer ? ` ${signer} signed this message; "Trust ${signer} as an intermediary" stops this warning for links through ${signer} in mail it signs.` : ` Nobody signed this message for ${url.hostname}, so there is no intermediary to trust; only the sender could vouch for the link.`;
       return {
@@ -2603,14 +2645,23 @@ function spamScoreOf(input) {
     proved: a.proved,
     provedBy: a.provedBy,
     bulkOnly: a.bulkOnly,
-    trusted: (!!input.senderTrusted && a.proved || !!a.intermediary) && a.kind !== "forgery" && !a.authFailures.length,
-    reasons: a.reasons
+    trusted: (!!input.senderTrusted && a.proved || !!a.intermediary || a.list.trusted) && a.kind !== "forgery" && !a.authFailures.length,
+    reasons: a.reasons,
+    listId: a.list.id,
+    listProved: a.list.proved,
+    listTrusted: a.list.trusted
   };
 }
-var FORGERY_RULES, ASSOCIATION_RULES, BULK_RULES, NEUTRAL_RULES, OVERLAY_MIN_EDGE_PX, RELAY_IDENTITY_HEADERS, ZERO_WIDTH_MIN_OCCURRENCES;
+var TRUST_LIST_KEYS, FORGERY_RULES, ASSOCIATION_RULES, BULK_RULES, NEUTRAL_RULES, LIST_RELAY_RULES, OVERLAY_MIN_EDGE_PX, RELAY_IDENTITY_HEADERS, ZERO_WIDTH_MIN_OCCURRENCES;
 var init_trust = __esm({
   "packages/mailx-types/trust.js"() {
     "use strict";
+    TRUST_LIST_KEYS = {
+      sender: "trustedSenders",
+      domain: "trustedDomains",
+      intermediary: "trustedIntermediaries",
+      list: "trustedLists"
+    };
     FORGERY_RULES = [
       /^SPF_(HELO_)?(FAIL|SOFTFAIL)$/,
       /^(KAM_)?DMARC_(FAIL|REJECT|QUAR)/,
@@ -2686,6 +2737,16 @@ var init_trust = __esm({
       /^NO_RELAYS$/,
       /^ALL_TRUSTED$/
     ];
+    LIST_RELAY_RULES = [
+      /^POSSIBLE_GMAIL_PHISHER$/,
+      // From gmail.com, not sent through Google
+      /^FREEMAIL_FORGED_FROMDOMAIN$/,
+      // From and envelope are different freemail domains
+      /^(NML_|DKIM_)ADSP_/,
+      // author domain did not sign what arrived
+      /^FORGED_[A-Z]+_RCVD$/
+      // From ‹provider› without ‹provider›'s Received
+    ];
     OVERLAY_MIN_EDGE_PX = 2e3;
     RELAY_IDENTITY_HEADERS = [
       "x-source-auth",
@@ -3089,6 +3150,7 @@ var mailx_types_exports = {};
 __export(mailx_types_exports, {
   CONTACT_RULES: () => CONTACT_RULES,
   REMINDER_STATE_FILE: () => REMINDER_STATE_FILE,
+  TRUST_LIST_KEYS: () => TRUST_LIST_KEYS,
   addContactsDenylistEntry: () => addContactsDenylistEntry,
   addContactsPreferredEntry: () => addContactsPreferredEntry,
   answeredOf: () => answeredOf,
@@ -4208,7 +4270,9 @@ var init_web_settings = __esm({
       flaggedSenders: [],
       flaggedDomains: [],
       trustedSenders: [],
-      trustedDomains: []
+      trustedDomains: [],
+      // Mailing lists by List-Id — mirrors mailx-settings DEFAULT_ALLOWLIST (2026-09-09).
+      trustedLists: []
     };
     PREV_KEEP = 5;
     SHARED_REFRESH_MS = 5 * 6e4;
@@ -7138,7 +7202,7 @@ var WebMailxService = class _WebMailxService {
       return { trusted: false };
     let trusted = false;
     await updateAllowlist((list) => {
-      const key = type === "sender" ? "trustedSenders" : type === "intermediary" ? "trustedIntermediaries" : "trustedDomains";
+      const key = TRUST_LIST_KEYS[type];
       const arr = Array.isArray(list[key]) ? list[key] : [];
       const idx = arr.findIndex((x) => (x || "").toLowerCase() === v);
       if (idx >= 0) {
@@ -7172,7 +7236,8 @@ var WebMailxService = class _WebMailxService {
       flaggedDomains: list.flaggedDomains || [],
       trustedSenders: list.trustedSenders || [],
       trustedDomains: list.trustedDomains || [],
-      trustedIntermediaries: list.trustedIntermediaries || []
+      trustedIntermediaries: list.trustedIntermediaries || [],
+      trustedLists: list.trustedLists || []
     };
   }
   async allowRemoteContent(type, value) {