@bobfrankston/rmfmail 1.2.299 → 1.2.300

package/.commitmsg

@@ -1,53 +1,41 @@
-Laundering needs a second party — a redirector alone is not one
-
-Google's account-security notice, which is exactly the mail a reader must be
-able to believe, carried a caution banner: "A link hides where it goes: it
-passes through accounts.google.com and ends at myaccount.google.com." Both
-halves of that sentence name Google. Bob, on the message:
-`mailxstore/bobma/e1/e193f2bb….eml`, "this is valid."
-
-The check compared `target.hostname === url.hostname` and reported anything
-else. That catches the case it was written for — `castanet-sa.fr/redirect.php
-?newurl=https://evil.example`, someone's abandoned redirect script spending a
-real business's reputation — but the comparison is not what the finding
-claims. Laundering requires a SECOND PARTY, someone whose name is on the
-visible link without their consent. Two ways a link has none, both now checked,
-neither of them a threshold:
-
-  1. The redirector and the destination are the same organisation. Equality
-     widened to the sub/parent-domain test this file already uses twice, now a
-     shared `sameOrg()` — deliberately not "the last two labels match", which
-     would make paypal.co.uk and evil.co.uk relatives.
-
-  2. The redirector IS the sender, proved. accounts.google.com and
-     myaccount.google.com are siblings, so rule 1 does not reach them; what
-     clears the message is that the receiving server recorded `dmarc=pass
-     header.from=accounts.google.com`. The host in the visible link belongs to
-     the party that provably sent the mail. Whether that party is trustworthy
-     is a different question than the one this check asks.
-
-The proof comes from `provedSenderDomain()`, which asks dmarcProof first — an
-Authentication-Results header alone is enough, so this works on Gmail-API mail
-with no SpamAssassin headers — and falls back to the DKIM_VALID_AU /
-ALL_TRUSTED proofs SpamAssassin states in its own rule list. It reads the
-topmost Authentication-Results only, which the sender cannot write. No proof
-means the check stays on: an escape a forger could open by typing a domain
-into From would be worse than no check.
-
-The mirror rule is NOT safe and is deliberately absent. "The link ENDS at the
-proved sender" would clear `legit-bank.com/r?u=https://evil.com` sent from a
-DMARC-proved evil.com, which is the laundering case in its purest form — the
-reader sees the bank's hostname. Only the visible host may be the sender's.
-
-Measured over the 800 most recent messages in the store: redirector-link fires
-15 times before, 4 after. Cleared: Substack's own link wrapper on Substack
-mail (6), Google's alert, Microsoft Teams, dev.to. Still flagged, correctly by
-this rule's terms: Microsoft's Safe Links wrapper (nam.safelink.emails.azure.net
--> admin.microsoft.com, 3) and a donation platform bouncing back to the charity
-that mailed. Those are third-party hostnames in front of the reader, and no
-hostname allowlist is going in to quiet them.
-
-Four tests: the sibling-subdomain case, the Google alert with its proof and
-again with the proof removed, and a forged accounts.google.com whose server
-recorded the DMARC failure — still flagged, as the escape is the server's
-verdict and never the From line's say-so.
+The chip claimed every rule was a bulk-mail test without looking at them
+
+Altis Hotels' welcome mail (Bob 2026-09-03: "marked as spam but is valid",
+`mailxstore/bobma/90/90fd2404….eml`). The banner on it is already right —
+`info`, no headline, "Your mail server scored this as spam, but altishotels.com
+proved it sent this", and the "Stop warning about marketing@altishotels.com"
+button underneath. What was wrong sat one element above: the score chip's
+tooltip read "Scored by bulk-mail or blocklist rules; the sending domain passed
+DMARC, so the sender is proved" — and then listed, on the next line of the same
+tooltip, `3.2 KAM_ACCOUNTPHISH (Spam that tries to get account information)`,
+which is 3.2 of the message's 8.3 and is neither a bulk-mail nor a blocklist
+rule. A reader who reads both lines has been told two different things about
+the same message by the same tooltip, and the app is the one that is wrong.
+
+The claim was never checked. `benign = proved || kind === "bulk"` picked the
+neutral chip — correctly, that part is about the sender — and the tooltip then
+described the RULES from that same flag. `proved` is a fact about the headers
+and says nothing about any rule; `kind` is the WORST class present and says
+nothing about the rest. Neither one can support a sentence beginning "every
+rule that scored".
+
+`analyzeServerSpam` now computes `bulkOnly` — every rule that scored is `bulk`
+or `neutral` — and `spamScoreOf` carries it to the chip. The bulk-only sentence
+is said only when it is true. Otherwise the tooltip says what IS established
+and nothing more: the proof, by name, plus "not every rule that scored is a
+bulk-mail test — they are listed below", or for an unproved sender "no forgery
+rule scored", which `kind === "bulk"` does establish. The `info` banner for a
+bulk verdict loses its "— nothing that scored tests who sent it" clause on the
+same condition, since it was making the same unchecked claim.
+
+Measured over the 800 newest messages in the store: 138 raise the neutral chip,
+and 132 of those were being told the score was bulk-mail rules only. Most are
+unflagged mail scoring above half the threshold, which carries no
+X-Spam-Report at all — there the individual scores are unknown, which is
+precisely when a claim about all of them cannot be made.
+
+Not changed, on purpose: KAM_ACCOUNTPHISH stays unclassified. Its description
+says it tests what the message asks for, not who sent it, but "other" is the
+honest answer for a rule this file has no basis to classify, and the cautious
+default is what "other" is for. The fix is to stop asserting past it, not to
+guess at it.

package/client/android-bootstrap.bundle.js

@@ -2318,6 +2318,7 @@ function analyzeServerSpam(input) {
   const unknown = rules.filter((r) => r.cls === "other" && scored(r));
   const unknownWeight = unknown.reduce((sum, r) => sum + r.score, 0);
   const unknownCouldFlagAlone = !unknown.length ? false : !Number.isFinite(unknownWeight) || !Number.isFinite(threshold) ? true : unknownWeight >= threshold;
+  const bulkOnly = rules.every((r) => !scored(r) || r.cls === "bulk" || r.cls === "neutral");
   const kind = dmarc.authFailures.length || present("forgery") ? "forgery" : present("association") ? "association" : unknownCouldFlagAlone ? "unclassified" : rules.length ? "bulk" : "unclassified";
   const has = (name) => rules.some((r) => r.name === name);
   const provedBy = dmarc.pass ? "dmarc" : has("DKIM_VALID_AU") ? "dkim" : has("ALL_TRUSTED") ? "trusted" : "";
@@ -2334,6 +2335,7 @@ function analyzeServerSpam(input) {
     kind,
     proved: !!provedBy,
     provedBy,
+    bulkOnly,
     provedDomain: dmarc.domain || fromDomain,
     provedPolicy: dmarc.policy,
     bayesHam: rules.some((r) => r.name === "BAYES_00" || r.name === "BAYES_01"),
@@ -2381,7 +2383,7 @@ function serverSpamVerdict(input) {
     return {
       id: "server-spam-verdict",
       severity: "info",
-      text: "Your mail server rates this bulk mail \u2014 nothing that scored tests who sent it.",
+      text: a.bulkOnly ? "Your mail server rates this bulk mail \u2014 nothing that scored tests who sent it." : "Your mail server rates this bulk mail.",
       detail: `${numbers}${why}${bayes}`
     };
   const proof = a.proved ? `${provedNote(a)} ` : "";
@@ -2561,6 +2563,7 @@ function spamScoreOf(input) {
     kind: a.kind,
     proved: a.proved,
     provedBy: a.provedBy,
+    bulkOnly: a.bulkOnly,
     trusted: !!input.senderTrusted && a.proved && a.kind !== "forgery" && !a.authFailures.length,
     reasons: a.reasons
   };