@bobfrankston/rmfmail 1.2.282 → 1.2.284

package/.commitmsg

@@ -1,62 +1,37 @@
-Catch the spam that scores under the threshold
-
-A sextortion mail arrived that none of yesterday's checks caught ("yet this
-spam got through"). SpamAssassin scored it 2.7 against a 4.5 threshold and
-delivered it, so server-spam-verdict correctly stayed silent — the server said
-no. Three independent proofs of forgery were sitting in the message anyway.
-
-spf=none now counts as "not authenticated" for self-claimed mail, not just
-fail. bobf.frankston.com publishes no SPF record, so nothing sent as that
-domain can ever FAIL — only come back none. Treating none as neutral left the
-least-protected domain the least defended, which is backwards. Checked against
-the real store before changing it, 50,000 messages scanned:
-
-  From at one of Bob's domains          10,338
-    no Authentication-Results           10,034   <- his own mail, still ignored
-    spf=pass                               243   <- still ignored
-    spf=fail / softfail                     33
-    spf=none                                18   <- nearly all spam
-
-The 18 were "Settle your debt", "AAA Final notice", "McAfee Protection Plan
-Ended" and similar. Legitimate self-mail sits in the no-header group: it never
-crossed a trust boundary, so there is no Authentication-Results to read, and
-that case is untouched. An explicit spf/dkim/dmarc=pass still silences the
-check.
-
-relay-auth-mismatch — Bob's own catch: "note that the origin is different than
-the from domain in antiabuse and in source-auth".
-
-  From:          universe@bobf.frankston.com
-  X-Source-Auth: admin@calebjross.com
-  X-Source-Cap:  (base64) calebjro;calebjro;box2202.bluehost.com
-  Message-ID:    <...@calebjross.com>
-
-A Bluehost cPanel account belonging to an unrelated domain authenticated and
-sent mail wearing his address. That stamp is written by the RELAY, downstream
-of whoever submitted the message, so a forger cannot remove or edit it — which
-makes the disagreement about as close to proof as mail headers get. Compared at
-the registrable-domain level, since a host legitimately sending for a domain
-authenticates as some account AT that domain and the local part varies for
-ordinary reasons. Covers the cPanel/Exim, Postfix and Communigate spellings.
-
-zero-width-obfuscation — the body had ~1380 zero-width characters stuffed
-between letters, so "i regret to inform you" reached every word-matching filter
-as gibberish while rendering as clean prose. SpamAssassin saw it
-(UNICODE_OBFU_ZW_MANY) and still totalled only 2.7. Counted only BETWEEN TWO
-LATIN LETTERS, which is what obfuscation looks like and what the legitimate
-uses are not: an emoji ZWJ joins pictographs, Arabic and Indic ZWNJ sit between
-their own scripts' letters. The occurrence count guards against a stray
-character surviving a copy-paste; it is a sanity bound, not a sensitivity dial.
-
-The score itself is now always visible — a chip above the body reading "spam
-score 2.7 of 4.5" ("should we have a flag ... with the spam assassin number and
-a color code?"). Separate from the findings on purpose: a finding is an
-accusation and fires only on evidence, this is a measurement. Colour is a
-PROPORTION of the server's own threshold — red once flagged, amber past halfway
-to its line, quiet below — so it follows if the server's threshold changes
-rather than hardcoding a number. Viewer only for now; the message-list row
-would need the score stored at sync time.
-
-tests/trust.test.ts covers all three, and the negative cases with them: spf=pass
-and no-header both silent, a relay identity at the same organisation, an emoji
-ZWJ family sequence, and a stray zero-width character from a paste.
+Pressing the icon while it is running raises the window instead of restarting
+
+"Why does it show and disappear? Are you assuring only a single instance? ...
+you should still put me in the running version when I press the icon on the
+task bar."
+
+Single instance was assured — by REPLACEMENT. Every launch that wasn't a
+share/mailto handoff ran replace-on-launch: SIGTERM the running daemon, wait,
+SIGKILL, then boot fresh. Press the taskbar icon and the window you already had
+is killed, disappears, and a new one fades up seconds later. From outside it
+reads as the app flickering out of existence for no reason.
+
+Replace-on-launch was written for the upgrade case — an older or orphaned daemon
+surviving a partial upgrade and leaving two windows on two versions — but it
+fired on every launch, ordinary ones included.
+
+instance.json already records the running version, so the two cases separate
+without guessing:
+
+  same version    the user wants the app, and it is already there — write
+                  pending-activate.json, let the running daemon raise its
+                  window, exit 0. Nothing is killed.
+  different       an upgrade landed; replace as before.
+
+The daemon answers with the same fs.watch + { _msgerWindow: "focus" } shape the
+mailto and share handoffs already use — that native control message exists
+precisely so a background daemon can surface its window, which is exactly this
+situation. It also consumes a request that arrived while it was still booting,
+since fs.watch only sees files that land after it is installed.
+
+`-another` still opts out entirely, and every handoff path still returns before
+reaching any of this.
+
+Verified against the live daemon before publishing: launching a second copy
+printed "already running (PID 34012, v1.2.283) — raising its window", exited 0,
+wrote the request, and left the running daemon alive — where the old code would
+have killed it.

package/bin/mailx.js

@@ -492,7 +492,17 @@ function readInstanceFile() {
 function writeInstanceFile(pid, childPids = []) {
     try {
         fs.mkdirSync(path.dirname(__instanceFile), { recursive: true });
-        const payload = { pid, version: __selfVersion, startedAt: Date.now(), childPids };
+        // startedAt must survive a childPids update. It was recomputed on every
+        // write, and since every popup and popout window rewrites this file,
+        // the field reported the last window event rather than when the daemon
+        // started — actively misleading when diagnosing "how long has this been
+        // up" or "which of these daemons is the old one" (it cost a wrong turn
+        // on 2026-08-27). Keep the existing value whenever the PID is unchanged.
+        const prev = readInstanceFile();
+        const startedAt = prev && prev.pid === pid && typeof prev.startedAt === "number"
+            ? prev.startedAt
+            : Date.now();
+        const payload = { pid, version: __selfVersion, startedAt, childPids };
         fs.writeFileSync(__instanceFile, JSON.stringify(payload, null, 2));
     }
     catch { /* non-fatal */ }
@@ -575,6 +585,19 @@ function touchHandoffStamp() {
     }
     catch { /* */ }
 }
+/** "Someone launched me while you are already running — show yourself."
+ *
+ *  A file rather than a socket, for the same reason the mailto and share
+ *  handoffs use one: the launching process is a fresh node that will exit in
+ *  milliseconds, and the daemon is already watching this directory. The daemon
+ *  side deletes it and sends the native focus command. */
+const __activateFile = path.join(path.dirname(__instanceFile), "pending-activate.json");
+function requestActivate() {
+    try {
+        fs.writeFileSync(__activateFile, JSON.stringify({ at: Date.now(), fromPid: process.pid }));
+    }
+    catch { /* */ }
+}
 if (!isDaemon && !__isCommandInvocation && !__keepOthers) {
     // Handoff launches must NOT replace a live daemon. rmfshare.exe (share
     // sheet) and rmfmailto.exe (mailto links) write a pending file and spawn
@@ -604,12 +627,35 @@ if (!isDaemon && !__isCommandInvocation && !__keepOthers) {
             }
         }
     }
-    // Replace-on-launch: any rmfmail daemon already running gets killed and
+    // Activate-on-launch: launching the SAME version that is already running
+    // raises the window that exists instead of replacing it.
+    //
+    // Replace-on-launch (below) was written for the upgrade case — an older or
+    // orphaned daemon surviving a partial upgrade and leaving two windows on
+    // two versions. But it fired on EVERY launch, including the ordinary one:
+    // press the taskbar icon, the new process SIGTERMs the running daemon, its
+    // window vanishes, and seconds later a fresh one appears. From the outside
+    // that reads as the app flickering out of existence for no reason (Bob
+    // 2026-08-26: "why does it show and disappear... you should still put me in
+    // the running version when I press the icon on the task bar").
+    //
+    // instance.json already records the running version, so the two cases are
+    // distinguishable without guessing: same version means the user wants the
+    // app, so surface it; a different version means an upgrade landed and the
+    // old daemon must go. `-another` still opts out entirely, and every handoff
+    // path above still returns before reaching here.
+    {
+        const inst0 = readInstanceFile();
+        if (inst0 && pidIsMailx(inst0.pid) && inst0.pid !== process.pid && inst0.version === __selfVersion) {
+            requestActivate();
+            console.log(`rmfmail: already running (PID ${inst0.pid}, v${inst0.version}) — raising its window`);
+            process.exit(0);
+        }
+    }
+    // Replace-on-launch: a daemon running a DIFFERENT version gets killed and
     // the new one takes over. instance.json only tracks ONE PID — older or
     // orphaned daemons can survive a partial upgrade and leave the user with
-    // multiple windows on different versions. Sweep PowerShell for any
-    // rmfmail-looking node process and kill it (unconditionally — version
-    // match alone isn't enough; we always want exactly one daemon).
+    // multiple windows on different versions.
     const myPid = process.pid;
     const killedPids = [];
     const inst = readInstanceFile();
@@ -681,6 +727,30 @@ if (!verbose && !isDaemon && !process.argv.slice(2).some(a => /^-/.test(a))) {
         windowsHide: true,
     });
     child.unref();
+    // Claim the instance slot for the child NOW, before we exit.
+    //
+    // Without this there is a multi-second hole in which no instance exists on
+    // paper: we spawn a detached daemon and exit immediately, but the daemon
+    // does not register itself until it has built the store, started the
+    // popout server and opened its window — several seconds later. Any launch
+    // arriving inside that hole reads instance.json, sees nothing alive, and
+    // starts ANOTHER daemon. That is how three of them ended up running at
+    // once on 2026-08-26, spawned 4 and 5 seconds apart (PIDs 1452, 34012,
+    // 94964), each with its own window, only one of them in instance.json —
+    // which is also why nothing came to the front and why replace-on-launch
+    // could never clean them up: it only ever knew about the last one to
+    // register (Bob: "this does not look like a single instance ... but not
+    // one of the windows came to the front").
+    //
+    // The child is alive from the moment spawn returns, and pidIsMailx is a
+    // liveness check, so the claim is valid immediately. If the child dies
+    // during boot the existing stale-PID check clears it on the next launch,
+    // and when the daemon does reach its own registration it writes the same
+    // PID again — no conflict. A launch that lands during boot now takes the
+    // activate path and drops pending-activate.json, which the daemon picks up
+    // when it starts watching. (Claude Code 2026-08-27)
+    if (typeof child.pid === "number")
+        writeInstanceFile(child.pid, []);
     process.exit(0);
 }
 const setupMode = hasFlag("setup");
@@ -3104,6 +3174,53 @@ RFC 5322 with CRLF line endings. Bodies are quoted-printable encoded (readable i
             console.error(`  [mailto] watch setup failed: ${e.message}`);
         }
     }
+    // Activation requests. A second launch of the SAME version (taskbar icon,
+    // Start menu, a double-clicked shortcut) drops pending-activate.json and
+    // exits instead of replacing us; this is the half that answers it by
+    // bringing the existing window to the front. Same fs.watch + native
+    // control-message shape as the mailto and share handoffs below.
+    //
+    // Without this the launcher would have nothing to hand off TO, and
+    // "already running — raising its window" would be a lie: the process would
+    // exit and the user would be left staring at whatever they were looking at
+    // before, which is worse than the restart it replaced.
+    {
+        try {
+            const dir = path.dirname(__activateFile);
+            const baseName = path.basename(__activateFile);
+            fs.mkdirSync(dir, { recursive: true });
+            // A request that landed while we were still booting — the watch
+            // below can only see files that arrive after it is installed.
+            if (fs.existsSync(__activateFile)) {
+                try {
+                    fs.unlinkSync(__activateFile);
+                }
+                catch { /* */ }
+                handle.send({ _msgerWindow: "focus" });
+            }
+            fs.watch(dir, (_event, filename) => {
+                if (filename !== baseName)
+                    return;
+                if (!fs.existsSync(__activateFile))
+                    return;
+                // Delete FIRST. fs.watch fires twice for one write on Windows
+                // (rename + change), and a second focus command is harmless but
+                // the unlink is what makes the second pass a no-op.
+                try {
+                    fs.unlinkSync(__activateFile);
+                }
+                catch {
+                    return;
+                }
+                touchHandoffStamp();
+                console.log("  [activate] second launch asked for the window — raising it");
+                handle.send({ _msgerWindow: "focus" });
+            });
+        }
+        catch (e) {
+            console.error(`  [activate] watch setup failed: ${e.message}`);
+        }
+    }
     // Pending Windows-share handler (C46). Same two-path pickup as mailto
     // above: the client's startup consumePendingShare poll covers the
     // "rmfshare.exe spawned us" race; this fs.watch covers shares that land