@bobfrankston/rmfmail 1.2.292 → 1.2.293

package/.commitmsg

@@ -1,29 +1,28 @@
-Trusting a sender must not turn on their tracking pixels
+The allowlist merge silently dropped any list it had not been taught
 
-Bob 2026-08-28, on a newsletter he subscribed to: "I don't need the spam
-reminder but I don't want to say show remote content in order to prevent
-tracking." He was right, and the shape of the bug is that the allowlist was
-answering two different questions with one list. The only gesture in the whole
-app that said "this correspondent is fine" was the remote-content banner's
-"Always: …", which buys a tracking pixel with every vote of confidence.
+Caught by driving the button from v1.2.292: pressing "Stop warning about
+*@digital.conservativeintel.com" returned `{trusted: true}`, the banner
+disappeared — and nothing was written. `trustedDomains` was empty on readback
+and absent from allowlist.jsonc.
 
-Two lists now, both in allowlist.jsonc:
+Cause: `saveAllowlist` merges the local copy with the cloud one so a second
+machine's entries survive, and that merge rebuilt the result from a HARDCODED
+list of the five fields it knew. The two lists added earlier the same day were
+dropped on the way to disk, with a success return the whole way up. A merge
+that must be taught each new field will keep losing the next one.
 
-  senders / domains                 load their images, and I trust them
-  trustedSenders / trustedDomains   ONLY stop warning me about them
+- `mergeAllowlists(local, cloud)` — extracted, exported, and tested — unions
+  every field present in either copy, discovering names at runtime. Arrays
+  union; anything else prefers the local side, since the caller is the one
+  making a change; no key either side has is ever dropped. That last property
+  is what keeps a second machine's entries alive and what saved this file in
+  the 2026-07-23 wipe.
+- `DEFAULT_ALLOWLIST` names trustedSenders/trustedDomains on both the desktop
+  and Android sides, so a fresh file has them.
+- The banner button no longer trusts a bare resolve: it only ever ADDS, so
+  anything but `trusted: true` is a failed write, and it says so on the button
+  instead of removing a banner that will come back. That check is what would
+  have caught this bug at the UI instead of at a grep of the JSON.
 
-Both feed `senderTrusted` in the store; only the first feeds `allowRemote`, and
-that line carries a comment saying why it must never be widened to the second.
-
-The trust note gains the action it was missing: **"Stop warning about
-‹address›"** and **"Stop warning about *@‹domain›"**, naming the sender rather
-than saying "this one" so the choice is checkable afterwards. New IPC
-`trustSenderOrDomain` (toggle, like flagSenderOrDomain) wired through all six
-places — service, jsonrpc, web-service, web-jsonrpc, android-bootstrap,
-api-client + mailxapi.js; the bridge-contract guard passes at 110 client calls.
-
-The buttons appear only where the server's own verdict is the WHOLE finding and
-the sender is proved. A forgery banner gets no such button: no list should be
-able to silence "this message is not what it says it is", and there is nothing
-to trust when identity is the thing in doubt. A failed write reports itself on
-the button rather than looking like it worked.
+tests/allowlist-merge.test.ts covers the shape that loses data, including a
+field named nowhere in the code.

package/client/android-bootstrap.bundle.js

@@ -4122,7 +4122,9 @@ var init_web_settings = __esm({
       domains: [],
       recipients: [],
       flaggedSenders: [],
-      flaggedDomains: []
+      flaggedDomains: [],
+      trustedSenders: [],
+      trustedDomains: []
     };
     PREV_KEEP = 5;
     SHARED_REFRESH_MS = 5 * 6e4;