@bobfrankston/rmfmail 1.2.313 → 1.2.314

package/.commitmsg

@@ -1,22 +1,27 @@
-Trusted lists: the action beside the warning, and a way to undo it
+Self-spoof: a DMARC-proved From is not a spoof, whatever else failed
 
-Bob 2026-09-09, after v1.2.312: "it would be nice to have an [approve
-this list] on the red warning banner" and "how would I undo an approval".
+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).
 
-An unflagged list post has no banner — the spam-score chip IS the warning
-— so "Trust the ‹List-Id› list" now sits beside the chip as a button, the
-same write as the banner button and the From-menu item. The red (danger)
-banner still carries no list button on purpose: over the last 120 days
-every proved-list post that stayed red (123 of 1,386 flagged list posts)
-was a phishing or malware URL listing on a throwaway domain that signs
-its own mail, and trusting a list never clears those, so a button there
-would be one that does nothing.
+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.
 
-Undo: once a list is trusted the chip and banner are gone, so the From
-address's right-click item is now offered on every proved post and reads
-"Stop trusting the ‹List-Id› mailing list" when the list is trusted — the
-toggle the write always was, finally reachable. The action checks that
-the answer went the way it asked and reports otherwise. docs/allowlist.md
-header reworded: the "do not edit" notice is about the .md itself;
-hand-editing allowlist.jsonc is fine and is how a sender or intermediary
-approval is undone until those get an undo of their own.
+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

@@ -46,4 +46,4 @@ tests/trust.test.ts, .commitmsg, TODO.md C165, root version 1.2.311. Then rebuil
 - [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.312)
-- [x] rebuild.cmd — published v1.2.312 + APK built (exit 0). App must be restarted to pick up the new bundle.
+- [x] rebuild.cmd — v1.2.312 (feature) + v1.2.313 (chip button + undo toggle) published, APKs built. Restart the app to pick up.

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" : "",