@bobfrankston/rmfmail 1.2.297 → 1.2.299

package/.commitmsg

@@ -1,32 +1,53 @@
-Reading a message outranks syncing it; a filter is not a selection
-
-Two things Bob hit on 2026-08-29.
-
-**"If I look at a letter while sync, things get confused. Eventually it reports
-an error rather than retrying. Viewing the body should get priority instead of
-waiting for sync."** Both halves were real:
-
-- Lanes are strictly sequential, and a click-time body fetch went on the tail
-  of the fast lane behind whatever background work was already queued.
-  `withConnection` now takes `priority`, which puts the task at the FRONT of
-  its lane; the interactive fetch uses it and a 30 s cap instead of 90 s. It
-  still cannot preempt the command in flight — an IMAP command cannot be
-  cancelled without dropping the connection — but it no longer waits out the
-  backlog.
-- `fetchMessageBody` swallowed every error into `null`. To the reconciler that
-  means "the server has no body for this message", which is classified
-  non-transient, skips the 3-attempt retry budget, and paints a banner. A lane
-  timeout says nothing about whether the message has a body: transient errors
-  (timeout, dropped socket, discarded client) now propagate, so the existing
-  retry-with-backoff applies and the reader gets the message instead of an
-  error. Only a genuine "no body here" still arms the prefetch backoff — a
-  timeout used to arm it too, poisoning the next view for up to 12 h.
-
-**"If I press * on search it shouldn't automatically select those letters, just
-show them."** Nothing was selected — the flagged-only filter washed the whole
-list in the flag colour (added 2026-06-26 to make the filter unmistakable), and
-a coloured background over rows is exactly how this list says "chosen". The
-wash is gone; the filter now announces itself above the list, by name:
-"Showing flagged (★) messages only — click to show everything", and clicking it
-clears the filter. Same chip covers the priority-senders filter, which had the
-same shape.
+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.

package/client/android-bootstrap.bundle.js

@@ -2226,6 +2226,13 @@ function bare(addr) {
   const m = (addr || "").match(/[^\s<>,;]+@[^\s<>,;]+/);
   return (m ? m[0] : addr || "").toLowerCase().replace(/[.,;]+$/, "");
 }
+function sameOrg(a, b) {
+  const x = (a || "").toLowerCase();
+  const y = (b || "").toLowerCase();
+  if (!x || !y)
+    return false;
+  return x === y || x.endsWith("." + y) || y.endsWith("." + x);
+}
 function classifyRule(name, dmarcFailed) {
   if (dmarcFailed && name === "DKIM_INVALID")
     return "forgery";
@@ -2455,7 +2462,17 @@ function hiddenLinkOverlay(bodyHtml) {
   }
   return null;
 }
-function redirectorLink(bodyHtml) {
+function provedSenderDomain(input) {
+  const fromDomain = (bare(input.fromAddress).split("@")[1] || "").toLowerCase();
+  if (!fromDomain)
+    return "";
+  if (dmarcProof(input).pass)
+    return fromDomain;
+  return analyzeServerSpam(input)?.proved ? fromDomain : "";
+}
+function redirectorLink(input) {
+  const bodyHtml = input.bodyHtml || "";
+  const senderDomain = provedSenderDomain(input);
   for (const m of bodyHtml.matchAll(/href\s*=\s*["']([^"']+)["']/gi)) {
     let url;
     try {
@@ -2465,6 +2482,8 @@ function redirectorLink(bodyHtml) {
     }
     if (!/^https?:$/.test(url.protocol))
       continue;
+    if (senderDomain && sameOrg(url.hostname, senderDomain))
+      continue;
     for (const [, value] of url.searchParams) {
       let target;
       try {
@@ -2474,7 +2493,7 @@ function redirectorLink(bodyHtml) {
       }
       if (!/^https?:$/.test(target.protocol))
         continue;
-      if (target.hostname === url.hostname)
+      if (sameOrg(target.hostname, url.hostname))
         continue;
       return {
         id: "redirector-link",
@@ -2493,7 +2512,7 @@ function assessMessageTrust(input) {
     relayAuthMismatch(input),
     zeroWidthObfuscation(input.bodyText || ""),
     hiddenLinkOverlay(input.bodyHtml || ""),
-    redirectorLink(input.bodyHtml || "")
+    redirectorLink(input)
   ].filter(Boolean);
   const rank = { danger: 0, caution: 1, info: 2 };
   return findings.sort((a, b) => rank[a.severity] - rank[b.severity]);
@@ -2506,9 +2525,7 @@ function relayAuthMismatch(input) {
   for (const name of RELAY_IDENTITY_HEADERS) {
     const stamped = bare(header(input.headerLines, name));
     const stampedDomain = stamped.split("@")[1] || "";
-    if (!stampedDomain || stampedDomain === fromDomain)
-      continue;
-    if (stampedDomain.endsWith("." + fromDomain) || fromDomain.endsWith("." + stampedDomain))
+    if (!stampedDomain || sameOrg(stampedDomain, fromDomain))
       continue;
     return {
       id: "relay-auth-mismatch",