@bobfrankston/mailx-types 0.1.104 → 0.1.106

package/package.json

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

package/trust.js

@@ -346,7 +346,22 @@ function dmarcProof(input) {
         && !fromDomain.endsWith("." + stated)) {
         return { pass: false, failed, authFailures, domain: "", policy };
     }
-    return { pass: true, failed: false, authFailures, domain: stated || fromDomain, policy };
+    // 2026-09-23 — Claude Code (Fable 5.1), at Bob's direction.
+    // An aligned DMARC pass IS the identity verdict: RFC 7489 pass means SPF or
+    // DKIM verified on the domain the reader sees in From. A failed mechanism
+    // beside it is about some OTHER identity — a relay's broken body hash, a
+    // forwarder's envelope — not about the From line. This function already
+    // said so for the aligned-pass case in selfSpoof ("one failed signature on
+    // a message with an aligned pass is not evidence about the From line; the
+    // pass is"), but authFailures still carried the DKIM name up to analyze-
+    // ServerSpam, where any authFailure forces kind = "forgery" and the red
+    // "not what it says it is" banner. Eversource's payment notice (SendGrid,
+    // dkim=fail on eversource.com's own signature, dmarc=pass header.from=
+    // notifications.eversource.com policy=reject) was painted as a forgery,
+    // and the trust button — gated on no danger — never appeared. Same shape
+    // as the list-relay carve-out at the call site, generalised to the case
+    // where the server itself pronounced the aligned verdict.
+    return { pass: true, failed: false, authFailures: [], domain: stated || fromDomain, policy };
 }
 /** Unfold a header value the way RFC 5322 folds it: delete the line break,
  *  KEEP the whitespace that continues the line. SpamAssassin breaks its tests=