@bobfrankston/rmfmail 1.2.312 → 1.2.313

package/client/components/message-viewer.ts

@@ -1381,22 +1381,35 @@ export async function showMessage(accountId: string, uid: number, folderId?: num
                     // Offered from the chip's own advice, which is the only
                     // thing an unflagged list post shows; the banner has its
                     // own button.
+                    //
+                    // Offered on every proved post, trusted or not: the write
+                    // is a toggle, and once the list is trusted the chip and
+                    // banner are gone, so this menu is the only place an
+                    // approval can be undone without editing allowlist.jsonc
+                    // by hand (Bob 2026-09-09: "how would I undo an approval").
                     const listSpam = (msg as any).spamScore as { listId?: string; listProved?: boolean; listTrusted?: boolean };
-                    if (listSpam?.listProved && listSpam.listId && !listSpam.listTrusted) {
+                    if (listSpam?.listProved && listSpam.listId) {
                         const listId = listSpam.listId;
+                        const untrust = !!listSpam.listTrusted;
                         items.push({
-                            label: `✓ Trust the ${listId} mailing list`,
+                            label: untrust ? `✗ Stop trusting the ${listId} mailing list` : `✓ Trust the ${listId} mailing list`,
                             action: async () => {
                                 const st = document.getElementById("status-sync");
                                 try {
-                                    // The action only ever ADDS, so anything but
-                                    // `trusted: true` means the write did not land.
+                                    // A toggle: the answer says which way it went,
+                                    // and it must match what was asked for — a
+                                    // mismatch means the write did not land.
                                     const res = await trustSenderOrDomain("list", listId);
-                                    if (!res?.trusted) throw new Error("the list did not save");
-                                    listSpam.listTrusted = true;
-                                    document.querySelector(".mv-spamscore")?.remove();
-                                    document.querySelector(".mv-trust")?.remove();
-                                    if (st) st.textContent = `Trusting the ${listId} mailing list`;
+                                    if (!res || !!res.trusted === untrust) throw new Error("the list did not save");
+                                    listSpam.listTrusted = res.trusted;
+                                    if (res.trusted) {
+                                        document.querySelector(".mv-spamscore")?.remove();
+                                        document.querySelector(".mv-spamscore-action")?.remove();
+                                        document.querySelector(".mv-trust")?.remove();
+                                    }
+                                    if (st) st.textContent = res.trusted
+                                        ? `Trusting the ${listId} mailing list`
+                                        : `No longer trusting the ${listId} mailing list — reopen the message to see its score again`;
                                 } catch (e: any) {
                                     // The reader chose an action and must know whether it took.
                                     if (st) {
@@ -1763,6 +1776,37 @@ export async function showMessage(accountId: string, uid: number, folderId?: num
                     : "");
             chip.textContent = `spam score ${spam.score} of ${spam.threshold}`;
             bodyEl.appendChild(chip);
+            // The action beside the warning it answers (Bob 2026-09-09: "it
+            // would be nice to have an [approve this list] on the red warning
+            // banner"). An unflagged list post has no banner — the chip IS
+            // the warning — so the button sits next to it. Same write as the
+            // From-menu item and the banner button: trustedLists by List-Id.
+            if (spam.listProved && spam.listId && !spam.listTrusted) {
+                const listId = spam.listId;
+                const b = document.createElement("button");
+                b.className = "mv-trust-action mv-spamscore-action";
+                b.textContent = `Trust the ${listId} list`;
+                b.title = `Delivered by the ${listId} mailing list, which your server proved sent it. Trusting the list hides this score on every post the list delivers.`;
+                b.addEventListener("click", async () => {
+                    b.disabled = true;
+                    try {
+                        // Only ever ADDS, so anything but `trusted: true` means
+                        // the write did not land — never hide the chip on a
+                        // failed save.
+                        const res = await trustSenderOrDomain("list", listId);
+                        if (!res?.trusted) throw new Error("the list did not save");
+                        spam.listTrusted = true;
+                        chip.remove();
+                        b.remove();
+                        document.querySelector(".mv-trust")?.remove();
+                    } catch (e: any) {
+                        // The reader pressed a button and must know whether it took.
+                        b.disabled = false;
+                        b.textContent = `Could not save: ${e?.message || e}`;
+                    }
+                });
+                bodyEl.appendChild(b);
+            }
         }
 
         const trust = ((msg as any).trust || []) as { id: string; severity: string; text: string; detail: string; via?: string; list?: string }[];

package/client/styles/components.css

@@ -3055,3 +3055,6 @@ body.calendar-sidebar-on .calendar-sidebar { display: flex; }
 /* Scored by bulk-mail or blocklist rules with the sender proved — the number
    is real and stays visible, but it is not an identity finding. */
 .mv-spamscore-bulk { background: oklch(0.55 0.02 250); color: white; font-weight: 600; }
+/* "Trust the ‹list› list" beside the chip — an unflagged list post has no banner,
+   so the chip is the warning and the action sits next to it (2026-09-09). */
+.mv-spamscore-action { margin: 0 0 var(--gap-sm) var(--gap-sm); vertical-align: baseline; }

package/docs/allowlist.md

@@ -1,6 +1,6 @@
 # allowlist.jsonc
 
-> **Owned by rmfmail. Do not edit this file — your changes will be overwritten the next time the app starts.** This is reference documentation. To change allow-list data, edit `allowlist.jsonc` itself.
+> **This documentation file (allowlist.md) is owned by rmfmail — do not edit it; it is rewritten every time the app starts.** The data file `allowlist.jsonc` next to it is yours: hand-editing it is fine and is one of the two ways to undo an approval (the other is the same viewer action again, see Notes).
 
 ## What this file documents
 
@@ -54,9 +54,11 @@ doing; a trusted list then quiets the spam note and hides the score chip. SPF an
 failures, and phishing or malware URL listings, are never silenced: a list member can post
 a bad link like anyone else.
 
-The viewer offers **"Trust the ‹List-Id› list"** under a spam-verdict banner, and
-**"Trust the ‹List-Id› mailing list"** in the From address's right-click menu (the chip's
-tooltip says so — an unflagged post shows only the chip).
+The viewer offers **"Trust the ‹List-Id› list"** under a spam-verdict banner and beside the
+spam-score chip (an unflagged post shows only the chip), and **"Trust the ‹List-Id› mailing
+list"** in the From address's right-click menu. Once the list is trusted the chip and banner
+are gone, so the menu item becomes **"Stop trusting the ‹List-Id› mailing list"** — that is
+how an approval is undone from the viewer.
 
 ## Notes
 
@@ -64,5 +66,5 @@ tooltip says so — an unflagged post shows only the chip).
 - Multi-client safe: each device's save merges with the cloud copy (set-union), so adds from any device propagate.
 - Use the message viewer's "allow remote content" button to add a sender/domain to `senders`/`domains` interactively.
 - Use the right-click menu in the viewer to flag a sender/domain — adds to `flaggedSenders`/`flaggedDomains`.
-- "Stop warning about …" under a spam-score note adds to `trustedSenders`/`trustedDomains`; "Trust … as an intermediary" adds to `trustedIntermediaries`; "Trust the … list" adds to `trustedLists`. Each is a toggle: the same action again removes the entry.
+- "Stop warning about …" under a spam-score note adds to `trustedSenders`/`trustedDomains`; "Trust … as an intermediary" adds to `trustedIntermediaries`; "Trust the … list" adds to `trustedLists`. Each is a toggle: the same action again removes the entry. The banner buttons disappear with the banner once trust is written, so to undo a sender or intermediary approval edit `allowlist.jsonc` (remove the entry from its list); a list approval can also be undone from the From address's right-click menu ("Stop trusting the … mailing list").
 - JSONC: `// line comments` and trailing commas are allowed.

package/docs/spam-false-positives.md

@@ -228,7 +228,7 @@ pass for the Sender:/bounce domain, or DKIM pass for the list domain; ISOC's Mai
 and the From-vs-path rules (`LIST_RELAY_RULES`) are neutral: the list is the explanation.
 Trusted + proved silences the verdict and hides the chip, like a trusted intermediary. SPF
 and DMARC failures and URL/phishing listings are never silenced — a list member can post a
-bad link like anyone else. Shipped v1.2.311; see `docs/allowlist.md`.
+bad link like anyone else. Shipped v1.2.312; see `docs/allowlist.md`.
 
 ## Follow-ups, 2026-08-27 evening
 

package/npmchanges.md

@@ -1712,3 +1712,45 @@ proof (DMARC pass, or DKIM_VALID_AU / ALL_TRUSTED per the existing proof
 logic); an unproved message with the same links stays flagged. mailx-types
 0.1.87.
 
+## v1.2.312 — 2026-09-10
+
+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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/rmfmail",
-  "version": "1.2.312",
+  "version": "1.2.313",
   "description": "Local-first email client with IMAP sync and standalone native app",
   "type": "module",
   "main": "bin/mailx.js",
@@ -34,8 +34,8 @@
   "dependencies": {
     "@bobfrankston/iflow-direct": "^0.1.68",
     "@bobfrankston/mailx-host": "^0.1.15",
-    "@bobfrankston/mailx-imap": "^0.1.178",
-    "@bobfrankston/mailx-store-web": "^0.1.111",
+    "@bobfrankston/mailx-imap": "^0.1.179",
+    "@bobfrankston/mailx-store-web": "^0.1.112",
     "@bobfrankston/mailx-sync": "^0.1.29",
     "@bobfrankston/miscinfo": "^1.0.21",
     "@bobfrankston/msger": "^0.1.431",
@@ -119,8 +119,8 @@
     "dependencies": {
       "@bobfrankston/iflow-direct": "^0.1.68",
       "@bobfrankston/mailx-host": "^0.1.15",
-      "@bobfrankston/mailx-imap": "^0.1.178",
-      "@bobfrankston/mailx-store-web": "^0.1.111",
+      "@bobfrankston/mailx-imap": "^0.1.179",
+      "@bobfrankston/mailx-store-web": "^0.1.112",
       "@bobfrankston/mailx-sync": "^0.1.29",
       "@bobfrankston/miscinfo": "^1.0.21",
       "@bobfrankston/msger": "^0.1.431",

package/packages/mailx-settings/docs/allowlist.md

@@ -1,6 +1,6 @@
 # allowlist.jsonc
 
-> **Owned by rmfmail. Do not edit this file — your changes will be overwritten the next time the app starts.** This is reference documentation. To change allow-list data, edit `allowlist.jsonc` itself.
+> **This documentation file (allowlist.md) is owned by rmfmail — do not edit it; it is rewritten every time the app starts.** The data file `allowlist.jsonc` next to it is yours: hand-editing it is fine and is one of the two ways to undo an approval (the other is the same viewer action again, see Notes).
 
 ## What this file documents
 
@@ -54,9 +54,11 @@ doing; a trusted list then quiets the spam note and hides the score chip. SPF an
 failures, and phishing or malware URL listings, are never silenced: a list member can post
 a bad link like anyone else.
 
-The viewer offers **"Trust the ‹List-Id› list"** under a spam-verdict banner, and
-**"Trust the ‹List-Id› mailing list"** in the From address's right-click menu (the chip's
-tooltip says so — an unflagged post shows only the chip).
+The viewer offers **"Trust the ‹List-Id› list"** under a spam-verdict banner and beside the
+spam-score chip (an unflagged post shows only the chip), and **"Trust the ‹List-Id› mailing
+list"** in the From address's right-click menu. Once the list is trusted the chip and banner
+are gone, so the menu item becomes **"Stop trusting the ‹List-Id› mailing list"** — that is
+how an approval is undone from the viewer.
 
 ## Notes
 
@@ -64,5 +66,5 @@ tooltip says so — an unflagged post shows only the chip).
 - Multi-client safe: each device's save merges with the cloud copy (set-union), so adds from any device propagate.
 - Use the message viewer's "allow remote content" button to add a sender/domain to `senders`/`domains` interactively.
 - Use the right-click menu in the viewer to flag a sender/domain — adds to `flaggedSenders`/`flaggedDomains`.
-- "Stop warning about …" under a spam-score note adds to `trustedSenders`/`trustedDomains`; "Trust … as an intermediary" adds to `trustedIntermediaries`; "Trust the … list" adds to `trustedLists`. Each is a toggle: the same action again removes the entry.
+- "Stop warning about …" under a spam-score note adds to `trustedSenders`/`trustedDomains`; "Trust … as an intermediary" adds to `trustedIntermediaries`; "Trust the … list" adds to `trustedLists`. Each is a toggle: the same action again removes the entry. The banner buttons disappear with the banner once trust is written, so to undo a sender or intermediary approval edit `allowlist.jsonc` (remove the entry from its list); a list approval can also be undone from the From address's right-click menu ("Stop trusting the … mailing list").
 - JSONC: `// line comments` and trailing commas are allowed.