@bobfrankston/rmfmail 1.2.312 → 1.2.314

package/.commitmsg

@@ -1,39 +1,27 @@
-Trusted mailing lists: "how do I say that this is a valid mailing list message"
+Self-spoof: a DMARC-proved From is not a spoof, whatever else failed
 
-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.
+Bob 2026-09-09, the ISOC Internet Policy list post, red banner "This
+message is not what it says it is — claims to be from your own address,
+internetpolicy@elists.isoc.org, but it did not come from your account.
+DKIM authentication failed". The list rewrote From to itself and signed
+it; iecc.com recorded dkim=pass d=elists.isoc.org and dmarc=pass
+header.from=elists.isoc.org — and dkim=fail for the original author's
+standardstrack.com signature the list had broken. Delivered-To was the
+list address, so it counted as one of Bob's own, and selfSpoof read every
+Authentication-Results and every signature and took the one failure as
+"did not come from your account". One broken signature on a message whose
+From domain passed DMARC aligned is not evidence about the From line; the
+pass is. selfSpoof now returns before the failure scan when dmarcProof
+passes for the actual From domain (a pass for some other domain still
+proves nothing — tested).
 
-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.
+Measured over the last 120 days: 977 messages whose From is their own
+Delivered-To, 35 self-spoof findings before, 20 after; the 15 cleared are
+all ISOC list posts, the 20 that remain are the sextortion/phish/NDA-scam
+mail the check exists for.
 
-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.
+Also: a danger banner on a proved-list post now says which list delivered
+it and that trusting the list (right-click the From address) would not
+clear the finding — a red banner with no way forward sends the reader
+hunting (Bob: "right mouse on the From … that's not obvious to the normal
+user"). mailx-types 0.1.90.

package/.llm/trusted-lists.md

@@ -37,10 +37,13 @@ web-service.ts + web-settings.ts DEFAULT_ALLOWLIST (+bump), client/lib/api-clien
 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.
 
+## Follow-up 2026-09-09 evening
+- Button beside the chip ("Trust the ‹List-Id› list"), From-menu item now toggles (Stop trusting…), docs reworded re editing allowlist.jsonc. Danger banners keep no list button: 123/123 proved-list danger cases in 120 days were URL phish/malware listings.
+
 ## 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
+- [x] docs/TODO/.commitmsg/versions (v1.2.312)
+- [x] rebuild.cmd — v1.2.312 (feature) + v1.2.313 (chip button + undo toggle) published, APKs built. Restart the app to pick up.

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.** **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] |
+| **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.312** (`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. **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. |
+| **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.312 — 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

@@ -2483,6 +2483,8 @@ function selfSpoof(input) {
   const auth = headerAll(input.headerLines, "authentication-results").join(" ; ");
   if (!auth)
     return null;
+  if (dmarcProof(input).pass)
+    return null;
   const failed = [
     /\bspf=(fail|softfail)\b/i.test(auth) ? "SPF" : "",
     /\bdkim=(fail|permerror)\b/i.test(auth) ? "DKIM" : "",