@bobfrankston/rmfmail 1.2.285 → 1.2.286

package/client/components/message-viewer.ts

@@ -1665,33 +1665,59 @@ export async function showMessage(accountId: string, uid: number, folderId?: num
         // prompted all of this scored 2.7 against 4.5 and was delivered
         // unflagged, so showing only the flagged ones would miss exactly the
         // case worth showing.
-        const spam = (msg as any).spamScore as { score: number; threshold: number; flagged: boolean };
+        //
+        // The COLOUR comes from what the rules that scored are evidence of, not
+        // from the number (Claude Code 2026-08-27): a newsletter DMARC proved,
+        // or one whose whole score is bulk-mail rules, gets the neutral chip
+        // however high it climbed. Blue Orchestra scored 10.9 on a Spamhaus
+        // listing of a linked advocacy site and a bulk-mail hit; painting that
+        // the same red as a forged sender is what teaches a reader to ignore
+        // the chip. The floor stays at half the server's own threshold —
+        // see docs/spam-false-positives.md on why tuning it is not the fix.
+        const spam = (msg as any).spamScore as {
+            score: number; threshold: number; flagged: boolean;
+            kind?: string; proved?: boolean; reasons?: string[];
+        };
         if (spam && Number.isFinite(spam.score) && (spam.flagged || spam.score >= spam.threshold / 2)) {
-            const level = spam.flagged ? "high" : "mid";
+            const benign = !!spam.proved || spam.kind === "bulk";
+            const level = benign ? "bulk" : spam.flagged ? "high" : "mid";
             const chip = document.createElement("div");
             chip.className = `mv-spamscore mv-spamscore-${level}`;
-            chip.title = level === "high"
-                ? "Your mail server scored this at or above its spam threshold and flagged it."
-                : "Below your server's spam threshold, but more than halfway to it.";
+            const why = (spam.reasons || []).length ? "\n\n" + spam.reasons.join("\n") : "";
+            chip.title = (level === "bulk"
+                ? (spam.proved
+                    ? "Scored by bulk-mail or blocklist rules; the sending domain passed DMARC, so the sender is proved."
+                    : "Every rule that scored is a bulk-mail test — none of them test who sent this.")
+                : level === "high"
+                    ? "Your mail server scored this at or above its spam threshold and flagged it."
+                    : "Below your server's spam threshold, but more than halfway to it.") + why;
             chip.textContent = `spam score ${spam.score} of ${spam.threshold}`;
             bodyEl.appendChild(chip);
         }
 
         const trust = ((msg as any).trust || []) as { id: string; severity: string; text: string; detail: string }[];
         if (trust.length) {
-            const worst = trust.some(f => f.severity === "danger") ? "danger" : "caution";
+            // An `info` finding is not an accusation, so it gets neither the
+            // headline nor the "do not open anything" footer — it renders as a
+            // plain note in the register of the remote-content banner. A single
+            // danger or caution finding anywhere in the set still sets the
+            // whole banner, because the worst evidence is the one that matters.
+            // (Claude Code 2026-08-27)
+            const worst = trust.some(f => f.severity === "danger") ? "danger"
+                : trust.some(f => f.severity === "caution") ? "caution" : "info";
+            const head = worst === "danger" ? "This message is not what it says it is"
+                : worst === "caution" ? "Check this message before acting on it" : "";
             const warn = document.createElement("div");
             warn.className = `mv-trust mv-trust-${worst}`;
             warn.innerHTML =
-                `<div class="mv-trust-head">${worst === "danger"
-                    ? "This message is not what it says it is"
-                    : "Check this message before acting on it"}</div>` +
+                (head ? `<div class="mv-trust-head">${head}</div>` : "") +
                 trust.map(f =>
                     `<div class="mv-trust-item mv-trust-${escapeText(f.severity)}">` +
                         `<div class="mv-trust-text">${escapeText(f.text)}</div>` +
                         `<div class="mv-trust-detail">${escapeText(f.detail)}</div>` +
                     `</div>`).join("") +
-                `<div class="mv-trust-foot">Links and attachments here should not be opened.</div>`;
+                (worst === "info" ? ""
+                    : `<div class="mv-trust-foot">Links and attachments here should not be opened.</div>`);
             bodyEl.appendChild(warn);
         }
 

package/client/styles/components.css

@@ -2945,6 +2945,12 @@ body.calendar-sidebar-on .calendar-sidebar { display: flex; }
 }
 .mv-trust-caution { box-shadow: inset 0 0 0 2px oklch(0.65 0.20 50); }
 
+/* `info` — the server said something, and it is not an accusation: bulk mail
+   from a sender DMARC proved. Grey, no headline, no "do not open" footer. A
+   red box on a newsletter Bob subscribed to is what teaches him to click past
+   the box that matters. (Claude Code 2026-08-27) */
+.mv-trust-info { box-shadow: inset 0 0 0 2px oklch(0.70 0.02 250); }
+
 .mv-trust-head {
     background: oklch(0.42 0.20 25);
     color: white;
@@ -2994,3 +3000,6 @@ body.calendar-sidebar-on .calendar-sidebar { display: flex; }
 }
 .mv-spamscore-mid  { background: oklch(0.55 0.18 50); color: white; font-weight: 600; }
 .mv-spamscore-high { background: oklch(0.42 0.20 25); color: white; font-weight: 700; }
+/* 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; }

package/docs/spam-false-positives.md

@@ -0,0 +1,208 @@
+# Spam false positives — why the trust banner fires on mail Bob asked for
+
+*Session note, 2026-08-27 (Claude Code), at v1.2.285. State: **first cut shipped
+2026-08-27** — ideas (1) and (2) below are implemented in `packages/mailx-types/trust.ts`
+with tests over all four samples in `tests/trust.test.ts`; sender trust (7) is still open.
+See "What shipped" at the end.*
+
+Bob 2026-08-27: *"better ideas for detecting false positives for spam"*, then
+*"Trusting senders may be a route."*
+
+## The four sample messages
+
+All still on disk under `C:\Users\Bob\.rmfmail\mailxstore\bobma\`:
+
+| file | sender | SA score | why it scored | Bayes | DMARC | Delivered-To |
+|---|---|---|---|---|---|---|
+| `f1/f1e6c04745e2403b89afa56de88af993.eml` | Blue Orchestra via Constant Contact | **10.9 YES** | `SH_DBL_HEADERS` 8.0 (blueorchestra.org in Spamhaus DBL) + `DCC_CHECK` 3.0 | BAYES_00 | pass, aligned, **p=reject** | actblue@bob.ma |
+| `cc/ccdf707f078b451697c68681f1dc0a2f.eml` | Adobe MAX | 3.9 no | 100% bulk rules: DCC_CHECK, DCC_REPUT_90_94, PYZOR_CHECK, MAILING_LIST_MULTI, HTML_FONT_SIZE_HUGE, HTML_IMAGE_RATIO_04, WORD_INVIS | BAYES_00 | pass, aligned, p=reject | adobe@bob.ma |
+| `9c/9c5a0904f8974558ac714d139ec8a235.eml` | Mokin via Shopify/SendGrid | **4.9 YES** | `URIBL_SBL` 6.0 | BAYES_00 | pass, aligned, p=quarantine | mokin@bob.ma |
+| `01/01fe446185024fd8beb851f8c29a87c2.eml` | Josh Shapiro via ActionKit | 2.2 (quiet — correct) | DCC_REPUT_70_89, KAM_TRACKIMAGE, URIBL_CSS_A, HTML_FONT_SIZE_LARGE | BAYES_00 | pass, aligned, p=reject | actblue@bob.ma |
+
+Two of the four raise the red banner ("This message is not what it says it is" /
+"Links and attachments here should not be opened"). Adobe raises the amber
+`spam score 3.9 of 4.5` chip. Shapiro is quiet.
+
+## What the sample proves
+
+**1. Shapiro is quiet by luck, not by discrimination.** The chip floor in
+`client/components/message-viewer.ts` is `spam.score >= spam.threshold / 2` = 2.25.
+Shapiro scored 2.2. It is the *same kind of mail* as Adobe — ESP-sent political/marketing
+bulk, same rule families. Landing 0.05 on the right side of an arbitrary line is not a
+classifier. **Do not respond by nudging that constant** — raising it to 0.75×threshold
+silences Adobe at 3.9 and still fires on the next legitimate newsletter at 4.0.
+
+**2. The big rules that flagged these are guilt by association, at third and fourth order.**
+Mokin's `X-Spam-Report` reads verbatim:
+
+```
+*  6.0 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL blocklist
+*      [URI: ns12.xincache.com/112.80.181.111]
+```
+
+link → its domain → that domain's nameserver → the nameserver's IP → SBL. Fourth order,
+worth more than the entire 4.5 threshold on its own. Blue Orchestra is the same shape:
+`SH_DBL_HEADERS` 8.0 because blueorchestra.org (a real advocacy org) sits in the DBL.
+Neither rule says anything about whether *this message* is forged.
+
+**3. Every one of the four carries `BAYES_00` (score 0.0000).** That is Bob's own
+SpamAssassin at gal.iecc.com, trained on years of Bob's own mail, saying 0–1% spam
+probability. Everything that pushed these over the line is a *network* rule about a third
+party, not a statement about the content.
+
+**4. Every one of the four passes DMARC, aligned, on a published reject/quarantine policy.**
+The domain owner staked their policy on it and the signature verified. The From line is
+*proved*. On such a message the headline "This message is not what it says it is" is
+**factually false**.
+
+**5. Every one arrived at a Bob-minted tag address**, and in two cases the tag names the
+sender's own domain: `mokin@bob.ma` → mokintech.com, `adobe@bob.ma` → adobe.com.
+
+## Root cause
+
+`serverSpamVerdict()` in `packages/mailx-types/trust.ts` consumes SpamAssassin's **bottom
+line** — a number tuned to answer "should this be delivered" — and reuses it to answer a
+different question, "is this forged", then prints the strongest banner in the app. The
+`tests=` list that would distinguish the two questions is in the same header and is never
+parsed. `spamScoreOf()` reads `score=` and `required=` out of `X-Spam-Status` and drops
+everything else.
+
+This is the same mistake trust.ts's own header warns against — its doctrine is
+*"Everything here is EVIDENCE… Each finding names what was found and what it means, so
+the reader can check it rather than trust a score."* The score finding is the one item in
+the file that is a bare number with no named evidence.
+
+## Ideas, ranked by leverage
+
+**1. A DMARC-aligned pass vetoes the danger headline.** ~10 lines, no tuning, kills the
+worst FP class outright. Does not make mail *wanted* — makes "not what it says it is"
+unsayable. Parse the existing `Authentication-Results` (already read by `selfSpoof`).
+
+**2. Classify `tests=` instead of summing it.** Three disjoint classes:
+
+- *bulk* — `DCC_*`, `PYZOR_*`, `RAZOR2_*`, `MAILING_LIST_MULTI`, `KAM_UNSUB1`,
+  `KAM_*MARKETINGBL*`, `KAM_TRACKIMAGE`, `KAM_REALLYHUGEIMGSRC`, `HTML_FONT_SIZE_*`,
+  `HTML_IMAGE_RATIO_*`, `MIME_HTML_ONLY`, `WORD_INVIS`, `HTML_TAG_BALANCE_*`,
+  `URIBL_GREY`, `URIBL_CSS_A`, `SH_BODYURI_REVERSE_CSS`
+- *forgery* — `SPF_FAIL`/`SOFTFAIL`, DKIM invalid **with** DMARC fail, `FORGED_*`, `SPOOF_*`
+- *guilt by association* — `URIBL_SBL`, `SH_DBL_HEADERS`, `URIBL_BLACK`
+
+A score composed entirely of the bulk class is a **bulk verdict**, however high. Adobe's
+3.9 is 100% bulk. Say "your server rates this bulk marketing" in the neutral register of
+the remote-content banner, or say nothing. Red is reserved for the forgery class.
+
+**3. `BAYES_00` is a demotion signal.** Flagged + BAYES_00 + DMARC-aligned means "network
+lists dislike a third party this message mentions", not "this resembles spam Bob receives".
+
+**4. The Delivered-To tag is a record of consent, and it is free.** Bob minted
+`mokin@bob.ma` and gave it to exactly one correspondent. When the tag's local part matches
+the authenticated sending domain, that is documented subscription. Needs no maintenance,
+unlike the allowlist. `deliveredTo` is already parsed at `packages/mailx-store/store.ts:543`
+and already flows to the viewer — nothing reads it for trust purposes.
+
+**5. Bob's own store is a better ham oracle than any RBL.** Prior messages from the same
+registrable domain that he read, replied to, or kept (not Junk, not deleted) — 50k+ rows of
+ground truth about his actual correspondents. A domain with 40 kept messages does not become
+a forger today because its nameserver landed in SBL.
+
+**6. Name the evidence for the score, as every other finding does.** `spam score 4.9 of 4.5`
+is unactionable; *"6.0 URIBL_SBL — the nameserver of a linked host is in Spamhaus SBL"* is
+judged in one second. Caveat found in the sample: `X-Spam-Report` appears only on flagged
+messages (present on Blue Orchestra + Mokin, absent on Adobe + Shapiro); `tests=` is always
+present, so degrade to rule names when the report is missing.
+
+**7. Extinguishable, not tuned** — see next section, this is the direction Bob picked.
+
+## Trusting senders — the direction Bob chose
+
+Bob 2026-08-27: *"Trusting senders may be a route."* Consistent with the standing rule that
+heuristic warnings should be **user-extinguishable rather than threshold-tuned**
+(memory: `allowlist_is_the_approved_sender_store`).
+
+What exists already and should be reused, not reinvented:
+
+- `allowlist.jsonc` **is** the approved-sender store; `getAllowlist()` at
+  `packages/mailx-service/index.ts:1980` returns
+  `{senders, domains, recipients, flaggedSenders, flaggedDomains}`, exposed over IPC at
+  `jsonrpc.ts:404` and bridged for Android at `mailx-store-web/android-bootstrap.ts:1794`.
+  Design doc: `docs/allowlist.md`.
+- The viewer already offers `✓ Trust all senders at <domain>` in the address context menu
+  (`client/components/message-viewer.ts:1371`), calling `approve("domain", dom)`.
+- `store.ts:570` already re-checks the recipient allowlist **with Delivered-To in hand** to
+  decide `allowRemote`. That is exactly the shape the trust suppression wants, one decision
+  earlier in the same function.
+
+What is missing:
+
+- Nothing consults the allowlist when computing `trust` / `spamScore` — an approved sender
+  still gets the red banner. `assessMessageTrust` is called at `store.ts:586` with no
+  allowlist input.
+- The trust banner has no inline action. A reader who has to find a context menu on an
+  address to say "this is mail I asked for" will not do it.
+
+Open design questions for next session:
+
+- **Trust key granularity**: envelope domain, From registrable domain, DKIM `d=` domain, or
+  the Delivered-To tag? Blue Orchestra argues against the From domain here —
+  `shared1.ccsend.com` is shared by every Constant Contact customer, so trusting it would
+  trust all of them; `blueorchestra.org` (Reply-To, and the domain in the DKIM-signed
+  `List-Unsubscribe`) is the real identity. Mokin argues the **tag** is the cleanest key —
+  `mokin@bob.ma` is single-purpose by construction.
+- Does trusting a sender suppress the *whole* banner, or only the bulk/association findings,
+  leaving genuine forgery evidence visible? Leaning: suppress the score chip and the
+  association findings, **never** the forgery class — a trusted domain can still be spoofed,
+  and that is precisely the case the banner exists for.
+- Auto-trust on a positive act (reply / move out of Junk / add to contacts) vs explicit only.
+
+## Recommended minimum first cut
+
+(1) + (2): DMARC-alignment veto plus rule classification. Together they silence all three
+false positives here and leave the 2026-08-25 sextortion/phish cases that motivated
+trust.ts untouched — those had spf=none/fail, no DKIM, no DMARC pass, and Bayes did not say
+0%. Sender-trust (7) then layers on top as the user-driven escape hatch rather than as the
+primary mechanism.
+
+## Files involved
+
+- `packages/mailx-types/trust.ts` — `serverSpamVerdict()`, `spamScoreOf()`, `assessMessageTrust()`
+- `packages/mailx-store/store.ts:586` — the single call site; has `deliveredTo`, `recipients`, raw `headerLines`
+- `client/components/message-viewer.ts:1655-1697` — the score chip (`threshold/2` floor) and the trust banner
+- `docs/allowlist.md` + `getAllowlist()` — the approved-sender store
+
+## What shipped, 2026-08-27
+
+Ideas (1) and (2), as the "recommended minimum first cut" below says. In
+`serverSpamVerdict()` / the new `analyzeServerSpam()` in
+`packages/mailx-types/trust.ts`:
+
+- `tests=` is parsed and every rule classified as **forgery**, **association**,
+  **bulk**, **neutral**, or **other** (`FORGERY_RULES` / `ASSOCIATION_RULES` /
+  `BULK_RULES` / `NEUTRAL_RULES`). A rule that scored zero or less cannot be the
+  reason a message is over the line, so it is not counted.
+- `X-Spam-Report` gives each rule its score and description, so findings name their
+  evidence — "8.0 SH_DBL_HEADERS (A domain found in headers … is listed in DBL)" —
+  and degrade to bare rule names when the report is absent (idea 6).
+- The **topmost** `Authentication-Results` is read for a DMARC-aligned pass, and its
+  `header.from=` is checked against the real From line. Only the topmost, because
+  headers are prepended: anything below it travelled with the message, and a forger
+  who could add `dmarc=pass` further down would have a switch for turning the banner
+  off.
+- Severity comes from the rules, never the number:
+  **danger** when a forgery rule fired or the server recorded an SPF/DKIM/DMARC
+  failure (phishing and malware URL listings count — a lookalike domain can get its
+  own valid DKIM); **info**, a new neutral severity with no headline and no
+  "do not open anything" footer, when the sender is proved and every rule that scored
+  is one the classifier can name, or the whole score is bulk; **caution** otherwise —
+  including a proved sender whose score came from unclassified rules, because unknown
+  is never a reason to go quiet. That last distinction is 326 messages in Bob's store.
+- `spamScoreOf()` returns `kind`, `proved` and `reasons` from the same analysis, so the
+  chip and the banner cannot disagree. The chip is grey when the sender is proved or
+  the score is all bulk, red only when the banner is. **The `threshold/2` floor is
+  unchanged.**
+
+Measured over 20,291 messages in the store: 1,131 were flagged spam, and every one of
+them used to get the red banner. Now 294 do (forgery), 672 are caution, 165 are quiet
+notes. All four samples above are quiet or neutral; the 2026-08-25 phishes stay red.
+
+Still open (C165): sender trust via `allowlist.jsonc`, the inline trust action on the
+banner, and the three design questions in the section above.

package/npmchanges.md

@@ -828,3 +828,43 @@ printed "already running (PID 34012, v1.2.283) — raising its window", exited 0
 wrote the request, and left the running daemon alive — where the old code would
 have killed it.
 
+## v1.2.285 — 2026-08-27
+
+Close the window where three daemons could start at once
+
+"This does not look like a single instance ... but not one of the windows came
+to the front." It wasn't one. Three daemons were running:
+
+  PID 1452    23:52:15.9
+  PID 34012   23:52:19.9   <- the only one instance.json knew about
+  PID 94964   23:52:25.0
+
+Launched 4 and 5 seconds apart, each with its own window, and replace-on-launch
+could never clean them up because it only ever knew about the last one to
+register. Win+4 could not raise "the" window because there were three of them
+and nothing owned the taskbar identity.
+
+The hole: the launcher spawns a DETACHED daemon and exits immediately, while
+the daemon does not register itself until it has built the store, started the
+popout server and opened its window — several seconds later. Every launch
+arriving inside that gap reads instance.json, sees nothing alive, and starts
+another daemon. Three launches within ten seconds, three daemons.
+
+The launcher now claims the slot for its child the moment spawn returns, before
+it exits. The child is alive from that instant and pidIsMailx is a liveness
+check, so the claim is valid straight away; when the daemon later reaches its
+own registration it writes the same PID again. A launch landing mid-boot now
+takes the activate path added in the previous release and drops
+pending-activate.json, which the daemon consumes as soon as it starts watching
+— which is exactly why that path checks for a request that arrived while it was
+booting.
+
+Also: startedAt was recomputed on EVERY write, and every popup and popout
+window rewrites this file, so the field reported the last window event rather
+than when the daemon started. It now survives childPids updates. That one cost
+a wrong turn while diagnosing this — the file claimed the daemon had started
+seconds ago when it had been up for minutes.
+
+Ships separately from the activate fix in 1.2.284 — verified that release did
+not already contain it.
+

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/rmfmail",
-  "version": "1.2.285",
+  "version": "1.2.286",
   "description": "Local-first email client with IMAP sync and standalone native app",
   "type": "module",
   "main": "bin/mailx.js",

package/packages/mailx-imap/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "@bobfrankston/mailx-imap",
-  "version": "0.1.160",
+  "version": "0.1.161",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bobfrankston/mailx-imap",
-      "version": "0.1.160",
+      "version": "0.1.161",
       "license": "ISC",
       "dependencies": {
         "@bobfrankston/iflow-direct": "^0.1.27",

package/packages/mailx-imap/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/mailx-imap",
-  "version": "0.1.160",
+  "version": "0.1.161",
   "type": "module",
   "main": "index.js",
   "types": "index.d.ts",

package/packages/mailx-service/index.ts

@@ -4861,12 +4861,29 @@ Resolve relative dates ("tomorrow", "next Friday") against today's date. If no y
                     // <name>": the editor is not the place to be censored.
                     // Disabled here rather than filtered client-side so the
                     // lint is never computed or shipped over IPC.
+                    //
+                    // CompoundNouns ("Did you mean the closed compound noun
+                    // “keypoint”?") fires on any noun+noun pair whose joined
+                    // form is in Harper's dictionary — Bob 2026-08-27 on "One
+                    // key point in my recent efforts": it invents a word he did
+                    // not write and marks correct English as an error. Same
+                    // objection as AvoidCurses: the tool proofreads, it does not
+                    // get a vote on word choice. Its siblings are still on
+                    // (MergeWords, MakeupCompoundNoun, OvertimeCompoundNoun,
+                    // ThereAfterCompound, EasyGoingCompoundAdjective) — add the
+                    // name here if one of them starts nagging.
+                    //
+                    // A partial setLintConfig MERGES: only the named keys change
+                    // and every other rule keeps its default. Rule names are
+                    // PascalCase and are NOT the user-visible message —
+                    // `JSON.parse(await linter.getLintConfigAsJSON())` lists all
+                    // ~750, getLintDescriptionsAsJSON() explains each.
                     try {
-                        await linter.setLintConfig({ AvoidCurses: false } as any);
+                        await linter.setLintConfig({ AvoidCurses: false, CompoundNouns: false } as any);
                     } catch (e: any) {
-                        console.warn(`  [grammar] could not disable AvoidCurses: ${e?.message || e}`);
+                        console.warn(`  [grammar] could not disable AvoidCurses/CompoundNouns: ${e?.message || e}`);
                     }
-                    console.log("  [grammar] Harper linter initialized (AvoidCurses off)");
+                    console.log("  [grammar] Harper linter initialized (AvoidCurses, CompoundNouns off)");
                     return linter;
                 })();
             }

package/packages/mailx-service/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/mailx-service",
-  "version": "0.1.28",
+  "version": "0.1.29",
   "type": "module",
   "main": "index.js",
   "types": "index.d.ts",

package/packages/mailx-settings/docs/spam-false-positives.md

@@ -0,0 +1,208 @@
+# Spam false positives — why the trust banner fires on mail Bob asked for
+
+*Session note, 2026-08-27 (Claude Code), at v1.2.285. State: **first cut shipped
+2026-08-27** — ideas (1) and (2) below are implemented in `packages/mailx-types/trust.ts`
+with tests over all four samples in `tests/trust.test.ts`; sender trust (7) is still open.
+See "What shipped" at the end.*
+
+Bob 2026-08-27: *"better ideas for detecting false positives for spam"*, then
+*"Trusting senders may be a route."*
+
+## The four sample messages
+
+All still on disk under `C:\Users\Bob\.rmfmail\mailxstore\bobma\`:
+
+| file | sender | SA score | why it scored | Bayes | DMARC | Delivered-To |
+|---|---|---|---|---|---|---|
+| `f1/f1e6c04745e2403b89afa56de88af993.eml` | Blue Orchestra via Constant Contact | **10.9 YES** | `SH_DBL_HEADERS` 8.0 (blueorchestra.org in Spamhaus DBL) + `DCC_CHECK` 3.0 | BAYES_00 | pass, aligned, **p=reject** | actblue@bob.ma |
+| `cc/ccdf707f078b451697c68681f1dc0a2f.eml` | Adobe MAX | 3.9 no | 100% bulk rules: DCC_CHECK, DCC_REPUT_90_94, PYZOR_CHECK, MAILING_LIST_MULTI, HTML_FONT_SIZE_HUGE, HTML_IMAGE_RATIO_04, WORD_INVIS | BAYES_00 | pass, aligned, p=reject | adobe@bob.ma |
+| `9c/9c5a0904f8974558ac714d139ec8a235.eml` | Mokin via Shopify/SendGrid | **4.9 YES** | `URIBL_SBL` 6.0 | BAYES_00 | pass, aligned, p=quarantine | mokin@bob.ma |
+| `01/01fe446185024fd8beb851f8c29a87c2.eml` | Josh Shapiro via ActionKit | 2.2 (quiet — correct) | DCC_REPUT_70_89, KAM_TRACKIMAGE, URIBL_CSS_A, HTML_FONT_SIZE_LARGE | BAYES_00 | pass, aligned, p=reject | actblue@bob.ma |
+
+Two of the four raise the red banner ("This message is not what it says it is" /
+"Links and attachments here should not be opened"). Adobe raises the amber
+`spam score 3.9 of 4.5` chip. Shapiro is quiet.
+
+## What the sample proves
+
+**1. Shapiro is quiet by luck, not by discrimination.** The chip floor in
+`client/components/message-viewer.ts` is `spam.score >= spam.threshold / 2` = 2.25.
+Shapiro scored 2.2. It is the *same kind of mail* as Adobe — ESP-sent political/marketing
+bulk, same rule families. Landing 0.05 on the right side of an arbitrary line is not a
+classifier. **Do not respond by nudging that constant** — raising it to 0.75×threshold
+silences Adobe at 3.9 and still fires on the next legitimate newsletter at 4.0.
+
+**2. The big rules that flagged these are guilt by association, at third and fourth order.**
+Mokin's `X-Spam-Report` reads verbatim:
+
+```
+*  6.0 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL blocklist
+*      [URI: ns12.xincache.com/112.80.181.111]
+```
+
+link → its domain → that domain's nameserver → the nameserver's IP → SBL. Fourth order,
+worth more than the entire 4.5 threshold on its own. Blue Orchestra is the same shape:
+`SH_DBL_HEADERS` 8.0 because blueorchestra.org (a real advocacy org) sits in the DBL.
+Neither rule says anything about whether *this message* is forged.
+
+**3. Every one of the four carries `BAYES_00` (score 0.0000).** That is Bob's own
+SpamAssassin at gal.iecc.com, trained on years of Bob's own mail, saying 0–1% spam
+probability. Everything that pushed these over the line is a *network* rule about a third
+party, not a statement about the content.
+
+**4. Every one of the four passes DMARC, aligned, on a published reject/quarantine policy.**
+The domain owner staked their policy on it and the signature verified. The From line is
+*proved*. On such a message the headline "This message is not what it says it is" is
+**factually false**.
+
+**5. Every one arrived at a Bob-minted tag address**, and in two cases the tag names the
+sender's own domain: `mokin@bob.ma` → mokintech.com, `adobe@bob.ma` → adobe.com.
+
+## Root cause
+
+`serverSpamVerdict()` in `packages/mailx-types/trust.ts` consumes SpamAssassin's **bottom
+line** — a number tuned to answer "should this be delivered" — and reuses it to answer a
+different question, "is this forged", then prints the strongest banner in the app. The
+`tests=` list that would distinguish the two questions is in the same header and is never
+parsed. `spamScoreOf()` reads `score=` and `required=` out of `X-Spam-Status` and drops
+everything else.
+
+This is the same mistake trust.ts's own header warns against — its doctrine is
+*"Everything here is EVIDENCE… Each finding names what was found and what it means, so
+the reader can check it rather than trust a score."* The score finding is the one item in
+the file that is a bare number with no named evidence.
+
+## Ideas, ranked by leverage
+
+**1. A DMARC-aligned pass vetoes the danger headline.** ~10 lines, no tuning, kills the
+worst FP class outright. Does not make mail *wanted* — makes "not what it says it is"
+unsayable. Parse the existing `Authentication-Results` (already read by `selfSpoof`).
+
+**2. Classify `tests=` instead of summing it.** Three disjoint classes:
+
+- *bulk* — `DCC_*`, `PYZOR_*`, `RAZOR2_*`, `MAILING_LIST_MULTI`, `KAM_UNSUB1`,
+  `KAM_*MARKETINGBL*`, `KAM_TRACKIMAGE`, `KAM_REALLYHUGEIMGSRC`, `HTML_FONT_SIZE_*`,
+  `HTML_IMAGE_RATIO_*`, `MIME_HTML_ONLY`, `WORD_INVIS`, `HTML_TAG_BALANCE_*`,
+  `URIBL_GREY`, `URIBL_CSS_A`, `SH_BODYURI_REVERSE_CSS`
+- *forgery* — `SPF_FAIL`/`SOFTFAIL`, DKIM invalid **with** DMARC fail, `FORGED_*`, `SPOOF_*`
+- *guilt by association* — `URIBL_SBL`, `SH_DBL_HEADERS`, `URIBL_BLACK`
+
+A score composed entirely of the bulk class is a **bulk verdict**, however high. Adobe's
+3.9 is 100% bulk. Say "your server rates this bulk marketing" in the neutral register of
+the remote-content banner, or say nothing. Red is reserved for the forgery class.
+
+**3. `BAYES_00` is a demotion signal.** Flagged + BAYES_00 + DMARC-aligned means "network
+lists dislike a third party this message mentions", not "this resembles spam Bob receives".
+
+**4. The Delivered-To tag is a record of consent, and it is free.** Bob minted
+`mokin@bob.ma` and gave it to exactly one correspondent. When the tag's local part matches
+the authenticated sending domain, that is documented subscription. Needs no maintenance,
+unlike the allowlist. `deliveredTo` is already parsed at `packages/mailx-store/store.ts:543`
+and already flows to the viewer — nothing reads it for trust purposes.
+
+**5. Bob's own store is a better ham oracle than any RBL.** Prior messages from the same
+registrable domain that he read, replied to, or kept (not Junk, not deleted) — 50k+ rows of
+ground truth about his actual correspondents. A domain with 40 kept messages does not become
+a forger today because its nameserver landed in SBL.
+
+**6. Name the evidence for the score, as every other finding does.** `spam score 4.9 of 4.5`
+is unactionable; *"6.0 URIBL_SBL — the nameserver of a linked host is in Spamhaus SBL"* is
+judged in one second. Caveat found in the sample: `X-Spam-Report` appears only on flagged
+messages (present on Blue Orchestra + Mokin, absent on Adobe + Shapiro); `tests=` is always
+present, so degrade to rule names when the report is missing.
+
+**7. Extinguishable, not tuned** — see next section, this is the direction Bob picked.
+
+## Trusting senders — the direction Bob chose
+
+Bob 2026-08-27: *"Trusting senders may be a route."* Consistent with the standing rule that
+heuristic warnings should be **user-extinguishable rather than threshold-tuned**
+(memory: `allowlist_is_the_approved_sender_store`).
+
+What exists already and should be reused, not reinvented:
+
+- `allowlist.jsonc` **is** the approved-sender store; `getAllowlist()` at
+  `packages/mailx-service/index.ts:1980` returns
+  `{senders, domains, recipients, flaggedSenders, flaggedDomains}`, exposed over IPC at
+  `jsonrpc.ts:404` and bridged for Android at `mailx-store-web/android-bootstrap.ts:1794`.
+  Design doc: `docs/allowlist.md`.
+- The viewer already offers `✓ Trust all senders at <domain>` in the address context menu
+  (`client/components/message-viewer.ts:1371`), calling `approve("domain", dom)`.
+- `store.ts:570` already re-checks the recipient allowlist **with Delivered-To in hand** to
+  decide `allowRemote`. That is exactly the shape the trust suppression wants, one decision
+  earlier in the same function.
+
+What is missing:
+
+- Nothing consults the allowlist when computing `trust` / `spamScore` — an approved sender
+  still gets the red banner. `assessMessageTrust` is called at `store.ts:586` with no
+  allowlist input.
+- The trust banner has no inline action. A reader who has to find a context menu on an
+  address to say "this is mail I asked for" will not do it.
+
+Open design questions for next session:
+
+- **Trust key granularity**: envelope domain, From registrable domain, DKIM `d=` domain, or
+  the Delivered-To tag? Blue Orchestra argues against the From domain here —
+  `shared1.ccsend.com` is shared by every Constant Contact customer, so trusting it would
+  trust all of them; `blueorchestra.org` (Reply-To, and the domain in the DKIM-signed
+  `List-Unsubscribe`) is the real identity. Mokin argues the **tag** is the cleanest key —
+  `mokin@bob.ma` is single-purpose by construction.
+- Does trusting a sender suppress the *whole* banner, or only the bulk/association findings,
+  leaving genuine forgery evidence visible? Leaning: suppress the score chip and the
+  association findings, **never** the forgery class — a trusted domain can still be spoofed,
+  and that is precisely the case the banner exists for.
+- Auto-trust on a positive act (reply / move out of Junk / add to contacts) vs explicit only.
+
+## Recommended minimum first cut
+
+(1) + (2): DMARC-alignment veto plus rule classification. Together they silence all three
+false positives here and leave the 2026-08-25 sextortion/phish cases that motivated
+trust.ts untouched — those had spf=none/fail, no DKIM, no DMARC pass, and Bayes did not say
+0%. Sender-trust (7) then layers on top as the user-driven escape hatch rather than as the
+primary mechanism.
+
+## Files involved
+
+- `packages/mailx-types/trust.ts` — `serverSpamVerdict()`, `spamScoreOf()`, `assessMessageTrust()`
+- `packages/mailx-store/store.ts:586` — the single call site; has `deliveredTo`, `recipients`, raw `headerLines`
+- `client/components/message-viewer.ts:1655-1697` — the score chip (`threshold/2` floor) and the trust banner
+- `docs/allowlist.md` + `getAllowlist()` — the approved-sender store
+
+## What shipped, 2026-08-27
+
+Ideas (1) and (2), as the "recommended minimum first cut" below says. In
+`serverSpamVerdict()` / the new `analyzeServerSpam()` in
+`packages/mailx-types/trust.ts`:
+
+- `tests=` is parsed and every rule classified as **forgery**, **association**,
+  **bulk**, **neutral**, or **other** (`FORGERY_RULES` / `ASSOCIATION_RULES` /
+  `BULK_RULES` / `NEUTRAL_RULES`). A rule that scored zero or less cannot be the
+  reason a message is over the line, so it is not counted.
+- `X-Spam-Report` gives each rule its score and description, so findings name their
+  evidence — "8.0 SH_DBL_HEADERS (A domain found in headers … is listed in DBL)" —
+  and degrade to bare rule names when the report is absent (idea 6).
+- The **topmost** `Authentication-Results` is read for a DMARC-aligned pass, and its
+  `header.from=` is checked against the real From line. Only the topmost, because
+  headers are prepended: anything below it travelled with the message, and a forger
+  who could add `dmarc=pass` further down would have a switch for turning the banner
+  off.
+- Severity comes from the rules, never the number:
+  **danger** when a forgery rule fired or the server recorded an SPF/DKIM/DMARC
+  failure (phishing and malware URL listings count — a lookalike domain can get its
+  own valid DKIM); **info**, a new neutral severity with no headline and no
+  "do not open anything" footer, when the sender is proved and every rule that scored
+  is one the classifier can name, or the whole score is bulk; **caution** otherwise —
+  including a proved sender whose score came from unclassified rules, because unknown
+  is never a reason to go quiet. That last distinction is 326 messages in Bob's store.
+- `spamScoreOf()` returns `kind`, `proved` and `reasons` from the same analysis, so the
+  chip and the banner cannot disagree. The chip is grey when the sender is proved or
+  the score is all bulk, red only when the banner is. **The `threshold/2` floor is
+  unchanged.**
+
+Measured over 20,291 messages in the store: 1,131 were flagged spam, and every one of
+them used to get the red banner. Now 294 do (forgery), 672 are caution, 165 are quiet
+notes. All four samples above are quiet or neutral; the 2026-08-25 phishes stay red.
+
+Still open (C165): sender trust via `allowlist.jsonc`, the inline trust action on the
+banner, and the three design questions in the section above.

package/packages/mailx-settings/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/mailx-settings",
-  "version": "0.1.62",
+  "version": "0.1.64",
   "type": "module",
   "main": "index.js",
   "types": "index.d.ts",

package/packages/mailx-store/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/mailx-store",
-  "version": "0.1.95",
+  "version": "0.1.97",
   "type": "module",
   "main": "index.js",
   "types": "index.d.ts",