@bobfrankston/rmfmail 1.2.298 → 1.2.299

package/.commitmsg

@@ -1,33 +1,53 @@
-The signature in accounts.jsonc never reached compose
-
-`sig` has been a documented field on AccountConfig for months and three of the
-four accounts carried one, yet no signature has ever appeared in a compose
-window. The reason is a projection: `MailxService.getAccounts()` builds the
-client's account list field by field — id/name/email from the DB row, then
-label, defaultSend, primary*, identityDomains from the config — and `sig` and
-`signature` were simply not on the list. `normalizeAccount()` resolved them
-correctly, `openCompose` forwarded `a.sig` faithfully, and compose.ts appended
-`acct.sig` exactly as designed; the value was undefined by the time any of that
-ran.
-
-Both fields are now carried, with a comment saying why the enumeration stays an
-enumeration rather than becoming `...cfg`: cfg holds the IMAP and SMTP
-passwords, which have no business crossing into the WebView. Anything new that
-the client needs has to be added in that spot deliberately.
-
-The signature itself moved to the top level of accounts.jsonc — three
-byte-identical per-account copies replaced by the one the file format already
-supports, which every account without its own `sig` inherits. It is now
-`Bob Frankston<br>https://Frankston.com` with `html: true`; the previous text
-relied on bare newlines for its line break (HTML collapses those to a space)
-and pointed at a relative `href='Frankston.com'`, which resolves against
-whatever page the mail client happens to be rendering.
-
-Two stale comments corrected while here. `AccountSignature.html` was documented
-in both mailx-types and compose.ts as "reserved for future use / currently
-ignored". It has never been ignored — compose has always branched on it — and
-now that a signature actually renders, the difference between escaped text and
-raw HTML is the thing an author needs to know.
-
-Compose only. Nothing in the send path or the daemon appends a signature; the
-body that leaves the editor is the body that goes out.
+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",