@bobfrankston/rmfmail 1.2.289 → 1.2.291

package/.commitmsg

@@ -1,12 +1,31 @@
-The spam chip has to name the proof it actually has
-
-Follow-up to v1.2.288, caught by looking at the rendered chip on Bob's own
-message: the banner correctly said "Valid signature from bob.ma (DKIM_VALID_AU)"
-while the chip's tooltip underneath asserted "the sending domain passed DMARC"
-— on a message that carries no Authentication-Results header at all. A claim
-the reader cannot check is exactly what this whole change set exists to remove.
-
-`SpamScore` now carries `provedBy` alongside `proved`, and the chip's tooltip
-says which of the three proofs applied: the server's DMARC verdict, a valid
-signature from the sending domain, or never having passed through an untrusted
-host.
+An approved sender, proved, says nothing at all
+
+Bob 2026-08-28, having just clicked "Always: *@icecer.com" on a conference call
+for papers that still showed a bulk-mail note: "I accepted the server so
+shouldn't this be considered safe?" Yes — and this is the half of C165 that was
+still open. `allowlist.jsonc` has been the approved-sender store all along, and
+nothing consulted it when computing trust.
+
+`assessMessageTrust` and `spamScoreOf` now take `senderTrusted`, and store.ts
+fills it from the sender and domain lists the reader maintains. When the sender
+is approved AND proved AND nothing accuses it of forgery, the server-spam
+finding is not rendered at all and the score chip goes with it: the score
+answers "is this bulk", the reader has already answered "is it wanted", and
+repeating the first after the second is how a banner becomes furniture.
+
+Three boundaries, deliberate:
+
+- **Trust never silences forgery evidence.** SPF_FAIL, a DMARC failure, a
+  FORGED_* rule, self-spoof, relay-auth mismatch — all still render, at full
+  severity, on a trusted sender.
+- **Trust counts only where the sender is PROVED** (DMARC, DKIM_VALID_AU, or
+  ALL_TRUSTED). Otherwise the approved-sender list would be a switch a forger
+  flips by typing a trusted address into From. A trusted address that cannot be
+  proved now gets a SHARPER warning than an untrusted one: "This claims to be a
+  sender you trust, but nothing proves it is."
+- **senderTrusted is narrower than allowRemote.** The recipient-alias list says
+  mail reached an address of the reader's, which permits images; it is not a
+  statement about who sent it, and the trust banner asks about the sender.
+
+The measurement is unchanged — spamScoreOf still reports the score, kind and
+reasons, with `trusted: true` alongside. Only the display goes.

package/TODO.md

@@ -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 (mailx-types 0.1.64, mailx-store 0.1.96):** `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. **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. |
 
 <a id="concerns"></a>
 

package/client/android-bootstrap.bundle.js

@@ -2308,7 +2308,10 @@ function analyzeServerSpam(input) {
   });
   const scored = (r) => !(r.score <= 0);
   const present = (cls) => rules.some((r) => r.cls === cls && scored(r));
-  const kind = dmarc.authFailures.length || present("forgery") ? "forgery" : present("association") ? "association" : present("other") ? "unclassified" : rules.length ? "bulk" : "unclassified";
+  const unknown = rules.filter((r) => r.cls === "other" && scored(r));
+  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 kind = dmarc.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();
@@ -2347,6 +2350,9 @@ function serverSpamVerdict(input) {
   const a = analyzeServerSpam(input);
   if (!a || !a.flagged)
     return null;
+  const trustedAndProved = input.senderTrusted && a.proved;
+  if (trustedAndProved && a.kind !== "forgery" && !a.authFailures.length)
+    return null;
   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)" : "";
@@ -2372,6 +2378,13 @@ function serverSpamVerdict(input) {
       detail: `${numbers}${why}${bayes}`
     };
   const proof = a.proved ? `${provedNote(a)} ` : "";
+  if (input.senderTrusted && !a.proved)
+    return {
+      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}`
+    };
   return {
     id: "server-spam-verdict",
     severity: "caution",
@@ -2531,6 +2544,7 @@ function spamScoreOf(input) {
     kind: a.kind,
     proved: a.proved,
     provedBy: a.provedBy,
+    trusted: !!input.senderTrusted && a.proved && a.kind !== "forgery" && !a.authFailures.length,
     reasons: a.reasons
   };
 }
@@ -2554,7 +2568,18 @@ var init_trust = __esm({
       /^SH_DBL/,
       /^SEM_URIBL/,
       /^SPAMHAUS_/,
-      /^RCVD_IN_(SBL|XBL|PBL|BL_SPAMCOP|SORBS|BRBL|VALIDITY|MSPIKE_[LZ])/
+      /^RCVD_IN_(SBL|XBL|PBL|BL_SPAMCOP|SORBS|BRBL|VALIDITY|MSPIKE_[LZ])/,
+      // Blocklist rules that happen to live under other prefixes. KAM_*URIBL_*
+      // ("Body contains URI listed in PCCC WILD RBL", 9.0) and SH_HBL_EMAILS
+      // ("Email address listed in email blocklist", 8.0) are the same kind of
+      // evidence as URIBL_SBL — somebody else's list, about a host or address
+      // the message mentions — and they were the bulk of what still cautioned a
+      // proved sender: a Business Insider newsletter, an MIT cancer-center
+      // invitation, a campaign mailing. KAM_INFOUSMEBIZ judges the TLD a domain
+      // lives in, which is guilt by neighbourhood.
+      /^KAM_(BODY_|FROM_)?URIBL/,
+      /^SH_HBL/,
+      /^KAM_INFOUSMEBIZ$/
     ];
     BULK_RULES = [
       /^DCC_/,
@@ -2582,7 +2607,14 @@ var init_trust = __esm({
       /^MPART_ALT_DIFF/,
       /^TVD_/,
       /^T_REMOTE_IMAGE$/,
-      /^UNPARSEABLE_RELAY$/
+      /^UNPARSEABLE_RELAY$/,
+      // Branded ESP click-trackers. Not open redirectors (URI_PHP_REDIR and
+      // friends stay unclassified): these are the sending platform's own
+      // tracking domain, which is mass-mail machinery by definition.
+      /^GB_AWSTRACK/,
+      /AWSTRACK/,
+      /^GB_SENDGRID/,
+      /^GB_MAILCHIMP/
     ];
     NEUTRAL_RULES = [
       /^BAYES_/,