@bobfrankston/rmfmail 1.2.290 → 1.2.291

package/.commitmsg

@@ -1,39 +1,31 @@
-Spam banner: an unknown rule must be able to condemn on its own
+An approved sender, proved, says nothing at all
 
-Bob 2026-08-28: "we have a problem since, of course, things like conference
-announcements use bulk mailers." An IEEE/ICECER call for papers, DMARC-proved,
-BAYES_00, scored exactly 4.5 of 4.5 — DCC_CHECK 3.0 + KAM_MARKETINGBL 1.0 +
-**1.5 GB_AWSTRACK_REDIR, Amazon SES's click-tracker** — and the one rule this
-file had never heard of pushed a proved announcement into "Check this message
-before acting on it / Links and attachments here should not be opened".
+Bob 2026-08-28, having just clicked "Always: *@icecer.com" on a conference call
+for papers that still showed a bulk-mail note: "I accepted the server so
+shouldn't this be considered safe?" Yes — and this is the half of C165 that was
+still open. `allowlist.jsonc` has been the approved-sender store all along, and
+nothing consulted it when computing trust.
 
-The "unknown means caution" policy was right; testing it by PRESENCE was not.
-An unknown rule now keeps a proved sender at caution only when it could have
-flagged the message BY ITSELF — its own scores summed against the server's own
-threshold. That adds no constant to tune: "enough to condemn" already has a
-number and it is the one the server used. KAM_BENEFICIARY, the case the policy
-exists for, is worth 10.0 alone and still cautions; a 1.5 click-tracker cannot.
-Unscored rules (no X-Spam-Report) leave the sum unknown, and unknown stays
-cautious.
+`assessMessageTrust` and `spamScoreOf` now take `senderTrusted`, and store.ts
+fills it from the sender and domain lists the reader maintains. When the sender
+is approved AND proved AND nothing accuses it of forgery, the server-spam
+finding is not rendered at all and the score chip goes with it: the score
+answers "is this bulk", the reader has already answered "is it wanted", and
+repeating the first after the second is how a banner becomes furniture.
 
-Two classification fixes found by sampling what still cautioned a PROVED
-sender across the store:
+Three boundaries, deliberate:
 
-- Branded ESP click-trackers (GB_AWSTRACK*, SendGrid, Mailchimp) are bulk-mail
-  machinery. Open redirectors (URI_PHP_REDIR and friends) stay unclassified —
-  a tracking domain the sending platform owns is not an abused redirect.
-- KAM_*URIBL_* ("Body contains URI listed in PCCC WILD RBL", 9.0) and
-  SH_HBL_EMAILS ("Email address listed in email blocklist", 8.0) are the same
-  evidence as URIBL_SBL — somebody else's list about a host the message
-  mentions — and were the bulk of the remaining noise: a Business Insider
-  newsletter, an MIT cancer-center invitation, a campaign mailing.
-  KAM_INFOUSMEBIZ judges the TLD a domain lives in, which is guilt by
-  neighbourhood.
+- **Trust never silences forgery evidence.** SPF_FAIL, a DMARC failure, a
+  FORGED_* rule, self-spoof, relay-auth mismatch — all still render, at full
+  severity, on a trusted sender.
+- **Trust counts only where the sender is PROVED** (DMARC, DKIM_VALID_AU, or
+  ALL_TRUSTED). Otherwise the approved-sender list would be a switch a forger
+  flips by typing a trusted address into From. A trusted address that cannot be
+  proved now gets a SHARPER warning than an untrusted one: "This claims to be a
+  sender you trust, but nothing proves it is."
+- **senderTrusted is narrower than allowRemote.** The recipient-alias list says
+  mail reached an address of the reader's, which permits images; it is not a
+  statement about who sent it, and the trust banner asks about the sender.
 
-Over the same 20,308 messages, of 1,131 flagged: 294 danger (unchanged — proof
-never overrides forgery), 278 caution, 559 quiet. What still cautions a proved
-sender is now almost entirely content-scam rules: ADVANCE_FEE, DEAR_BENEFICIARY,
-KAM_CRIM, UNDISC_MONEY, BITCOIN_DIRECT. The two false positives left in that
-set — a Substack news digest about displacement tripping KAM_CRIM, a Qatar
-Airways statement tripping BITCOIN_DIRECT — are exactly what sender trust is
-for, and are deliberately NOT being fixed by inventing more rule exceptions.
+The measurement is unchanged — spamScoreOf still reports the score, kind and
+reasons, with `trusted: true` alongside. Only the display goes.

package/client/android-bootstrap.bundle.js

@@ -2350,6 +2350,9 @@ function serverSpamVerdict(input) {
   const a = analyzeServerSpam(input);
   if (!a || !a.flagged)
     return null;
+  const trustedAndProved = input.senderTrusted && a.proved;
+  if (trustedAndProved && a.kind !== "forgery" && !a.authFailures.length)
+    return null;
   const numbers = Number.isFinite(a.score) && Number.isFinite(a.threshold) ? `SpamAssassin score ${a.score} of ${a.threshold}` : "flagged by SpamAssassin";
   const why = a.reasons.length ? ` \u2014 ${a.reasons.join("; ")}` : "";
   const bayes = a.bayesHam ? "; your own trained filter puts it at 0-1% spam (BAYES_00)" : "";
@@ -2375,6 +2378,13 @@ function serverSpamVerdict(input) {
       detail: `${numbers}${why}${bayes}`
     };
   const proof = a.proved ? `${provedNote(a)} ` : "";
+  if (input.senderTrusted && !a.proved)
+    return {
+      id: "server-spam-verdict",
+      severity: "caution",
+      text: "This claims to be a sender you trust, but nothing proves it is.",
+      detail: `No DMARC pass, no valid signature from the sending domain, and it passed through hosts your server does not trust. ${numbers}${why}`
+    };
   return {
     id: "server-spam-verdict",
     severity: "caution",
@@ -2534,6 +2544,7 @@ function spamScoreOf(input) {
     kind: a.kind,
     proved: a.proved,
     provedBy: a.provedBy,
+    trusted: !!input.senderTrusted && a.proved && a.kind !== "forgery" && !a.authFailures.length,
     reasons: a.reasons
   };
 }