@bobfrankston/mailx-settings 0.1.66 → 0.1.68

package/docs/spam-false-positives.md

@@ -206,3 +206,37 @@ notes. All four samples above are quiet or neutral; the 2026-08-25 phishes stay
 
 Still open (C165): sender trust via `allowlist.jsonc`, the inline trust action on the
 banner, and the three design questions in the section above.
+
+## Follow-ups, 2026-08-27 evening
+
+**Proof of the From line has three sources, not one** (v1.2.288). Bob: "why is my own
+mail spam". His reply to John Levine about spam handling carried NO
+`Authentication-Results` header — his own authenticated submission never crossed a trust
+boundary, so nothing wrote one — and fell through to a caution banner telling him not to
+open the links in prose he had just written. What scored it was `URIBL_DBL_SPAM` 8.0 on
+**blueorchestra.org: the domain he was quoting, in a discussion about spam.**
+
+SpamAssassin states two proofs in its own rule list that such mail carries instead:
+
+    * -1.0 ALL_TRUSTED    Passed through trusted hosts only via SMTP
+    * -0.1 DKIM_VALID_AU  Message has a valid DKIM or DK signature from author's domain
+
+`DKIM_VALID_AU` is the same evidence DMARC alignment rests on. `ALL_TRUSTED` says nothing
+untrusted handled the message in transit. `proved` now accepts any of the three and
+`provedBy` names which, so the banner (and the chip's tooltip, v1.2.289) says WHICH proof
+rather than asserting a DMARC pass that is not in the headers. Distribution over the same
+20,307 messages: danger unchanged at 294, caution 599, quiet 238.
+
+**John Levine, on the same thread, confirming the sender-trust direction:**
+
+> `* 3.0 DCC_CHECK Detected as bulk mail by DCC` — This means it's bulk mail, other people
+> have seen at least 20 messages like it. You have to whitelist the senders if you want to
+> keep them out of the spam folder. I have my own whitelist but I haven't tried to do a
+> global one because everyone's different. You may like mail from actblue, but the mail
+> they send to my father is spam because he's been dead for seven years.
+
+That is the argument for (7) and against any shared or tuned list: bulk is a fact about
+the mail, wanted is a fact about the reader. It also rules out server-side whitelisting as
+the answer for Bob specifically — he whitelists `@bob.ma` at the server and says "that
+gets abused", which is what forging his own domain buys an attacker. The client-side list
+must key on evidence (DKIM-verified domain, Delivered-To tag) rather than on the From line.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/mailx-settings",
-  "version": "0.1.66",
+  "version": "0.1.68",
   "type": "module",
   "main": "index.js",
   "types": "index.d.ts",
@@ -17,7 +17,7 @@
   },
   "license": "ISC",
   "dependencies": {
-    "@bobfrankston/mailx-types": "^0.1.68",
+    "@bobfrankston/mailx-types": "^0.1.71",
     "jsonc-parser": "^3.3.1"
   },
   "repository": {
@@ -33,7 +33,7 @@
   },
   ".transformedSnapshot": {
     "dependencies": {
-      "@bobfrankston/mailx-types": "^0.1.68",
+      "@bobfrankston/mailx-types": "^0.1.71",
       "jsonc-parser": "^3.3.1"
     }
   }