@bobfrankston/rmfmail 1.2.313 → 1.2.315

package/.commitmsg

@@ -1,22 +1,17 @@
-Trusted lists: the action beside the warning, and a way to undo it
+Self-spoof: the From domain's own SPF or DKIM pass is proof, DMARC verdict or not
 
-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".
+Follow-up to v1.2.314 (which vetoed the self-spoof finding on a DMARC pass).
+The AMW list (berglist.com) publishes no DMARC policy, so its posts carry
+no dmarc= verdict at all — but iecc.com recorded spf=pass for
+amw-bounces@berglist.com and dkim=pass d=berglist.com, which is the very
+evidence DMARC would have aligned on. The dkim=fail beside them was the
+gmail.com author signature the list broke, and the post was red as a spoof
+of the list's own address (Delivered-To). New alignedPass() in trust.ts:
+a verified signature for the From domain, or an SPF pass for an envelope at
+the From domain, computed as DMARC's relaxed alignment; a forger's pass for
+their own domain clears 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.
-
-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.
+Store, last 120 days, messages whose From is their own Delivered-To: 977;
+self-spoof findings 35 before v1.2.314, 20 after it, 15 now. The 15 that
+remain are the sextortion, "failed to deliver", NDA-review and
+document-share phishes the check exists for. mailx-types 0.1.91.

package/.llm/trusted-lists.md

@@ -40,10 +40,14 @@ tests/trust.test.ts, .commitmsg, TODO.md C165, root version 1.2.311. Then rebuil
 ## 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.
 
+## Self-spoof false positive (found from Bob's screenshot, 2026-09-09 late)
+- ISOC + berglist posts red as "claims to be from your own address": Delivered-To = list address = From, and selfSpoof took ANY dkim=fail in ANY Authentication-Results as proof of forgery. v1.2.314: DMARC-aligned pass vetoes. Next (v1.2.315): alignedPass() — From domain's own SPF pass or DKIM pass vetoes (relaxed alignment for domains with no DMARC policy). Store: 35 → 20 → 15 findings; the 15 are real phish.
+- Danger banner on a proved-list post now names the list and says right-click From / that trust would not clear it.
+
 ## 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.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

@@ -2267,6 +2267,23 @@ function dkimSigners(input) {
   }
   return out;
 }
+function alignedPass(input) {
+  const fromDomain = (bare(input.fromAddress).split("@")[1] || "").toLowerCase();
+  if (!fromDomain)
+    return "";
+  if (dkimSigners(input).some((d) => sameOrg(d, fromDomain)))
+    return "dkim";
+  const auth = headerAll(input.headerLines, "authentication-results")[0] || "";
+  for (const part of auth.split(";")) {
+    if (!/\bspf=pass\b/i.test(part))
+      continue;
+    const mailfrom = (part.match(/(?:spf|smtp)\.mailfrom=([^\s;,]+)/i)?.[1] || "").toLowerCase();
+    const domain = mailfrom.includes("@") ? mailfrom.split("@")[1] : mailfrom;
+    if (domain && sameOrg(domain, fromDomain))
+      return "spf";
+  }
+  return "";
+}
 function provedIntermediary(input) {
   const list = (input.trustedIntermediaries || []).map((d) => (d || "").trim().toLowerCase()).filter(Boolean);
   if (!list.length)
@@ -2483,6 +2500,8 @@ function selfSpoof(input) {
   const auth = headerAll(input.headerLines, "authentication-results").join(" ; ");
   if (!auth)
     return null;
+  if (dmarcProof(input).pass || alignedPass(input))
+    return null;
   const failed = [
     /\bspf=(fail|softfail)\b/i.test(auth) ? "SPF" : "",
     /\bdkim=(fail|permerror)\b/i.test(auth) ? "DKIM" : "",