@bobfrankston/rmfmail 1.2.300 → 1.2.302

package/.commitmsg

@@ -1,41 +1,49 @@
-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.
+Opening a PDF on the phone: a stub, and bytes laundered through UTF-8
+
+"I tried opening a pdf attachment on Android and it said 'opening' but nothing
+happened" (Bob 2026-09-04). In the Android log, verbatim:
+
+    Couldn't open "260901-THE-AI-COMPUTE-RACE-…-PRIVATE-DRAFT.pdf":
+    Not implemented on Android: getAttachment
+
+Two independent bugs, and only the first was reachable.
+
+**getAttachment was a `notImpl` stub.** It sat one line above a comment that
+read "Android opens attachments via the native bridge — getAttachment + base64
+hand-off covers it": a correct description of the design, immediately below the
+throw that made the design impossible. The viewer's Android branch does exactly
+what the comment says — fetch the bytes, hand them to
+`_nativeBridge.openAttachment` — so the throw landed in the chip's catch, which
+posts a banner and restores the label after 600ms. From the phone that is
+"Opening…", and then the chip goes back to normal. It is now implemented: read
+the body through the sync manager, parse, index the attachment the same way
+getMessage numbered the chips, return base64 in the shape the desktop jsonrpc
+returns.
+
+**The parser was destroying the bytes anyway.** The attachment branch called
+`decodeBody()` — which decodes the transfer encoding to bytes and then decodes
+THOSE as UTF-8 text — and re-encoded the result with `TextEncoder`. Every byte
+sequence that is not valid UTF-8 became U+FFFD and came back as the three bytes
+EF BF BD. A PDF, an image or a zip would have arrived corrupt and LONGER than
+it started, with `size` wrong to match, the moment the stub was filled in. The
+transfer-encoding step is now `decodeBodyBytes()` and stops at bytes;
+`decodeBody` is that plus the charset step, so the encodings still have one
+implementation. Attachments take the bytes. Text parts are unaffected.
+
+Verified against the actual message: the web parser and mailparser now produce
+byte-identical output for that PDF — 3,307,996 bytes, `%PDF-` to `%%EOF`.
+tests/attachment-bytes.test.ts covers it with a fixture built from bytes no
+UTF-8 decoder can round-trip, asserting the whole buffer rather than a prefix,
+because the broken version also started with "%PDF".
+
+**One more thing that had never run.** `app/openattachment` in MainPage.xaml.cs
+is the only place in the bridge that reads a RETURN VALUE from JS; every other
+path pushes C#→JS. Since the JS threw first, that code has never once executed.
+Android's evaluateJavascript hands back a JSON-encoded value, so the base64
+arrives quoted and with `=` liable to appear as = — undone before decode,
+and a FormatException now logs the length and first characters of what actually
+arrived instead of dying as "invalid base64".
+
+Untested from here: the 3.3 MB hand-off itself. The bytes are correct and the
+call is wired; whether a payload that size survives one EvaluateJavaScriptAsync
+can only be answered on the device. If it does not, the new log line names it.

package/client/android-bootstrap.bundle.js

@@ -6841,13 +6841,13 @@ function parseMimeParts(body, boundary, topHeaders) {
     }
     if (disposition.includes("attachment") || partType.includes("application/") && !partType.includes("text/")) {
       const filenameMatch = disposition.match(/filename="?([^";\r\n]+)"?/i) || partType.match(/name="?([^";\r\n]+)"?/i);
-      const decoded = decodeBody(partBody, partEncoding);
+      const content = decodeBodyBytes(partBody, partEncoding);
       attachments.push({
         filename: filenameMatch?.[1]?.trim() || `attachment-${attachments.length}`,
         contentType: partType.split(";")[0].trim(),
-        size: decoded.length,
+        size: content.length,
         contentId: (partHeaders.get("content-id") || "").replace(/[<>]/g, ""),
-        content: new TextEncoder().encode(decoded)
+        content
       });
     } else if (partType.includes("text/html")) {
       const charsetMatch = partType.match(/charset="?([^";\s]+)"?/i);
@@ -6859,14 +6859,21 @@ function parseMimeParts(body, boundary, topHeaders) {
   }
   return { html, text, headers: topHeaders, attachments };
 }
-function decodeBody(body, encoding, charset = "utf-8") {
+function base64FromBytes(bytes) {
+  const CHUNK = 32768;
+  let binary = "";
+  for (let i = 0; i < bytes.length; i += CHUNK)
+    binary += String.fromCharCode(...bytes.subarray(i, i + CHUNK));
+  return btoa(binary);
+}
+function decodeBodyBytes(body, encoding) {
   let bytes;
   if (encoding === "base64") {
     try {
       const binary = atob(body.replace(/\s/g, ""));
       bytes = Uint8Array.from(binary, (c) => c.charCodeAt(0));
     } catch {
-      return body;
+      bytes = Uint8Array.from(body, (c) => c.charCodeAt(0) & 255);
     }
   } else if (encoding === "quoted-printable") {
     const cleaned = body.replace(/=\r?\n/g, "");
@@ -6884,8 +6891,14 @@ function decodeBody(body, encoding, charset = "utf-8") {
   } else if (encoding === "7bit" || encoding === "8bit" || encoding === "" || encoding === "binary") {
     bytes = Uint8Array.from(body, (c) => c.charCodeAt(0) & 255);
   } else {
-    return body;
+    bytes = Uint8Array.from(body, (c) => c.charCodeAt(0) & 255);
   }
+  return bytes;
+}
+function decodeBody(body, encoding, charset = "utf-8") {
+  if (!["base64", "quoted-printable", "7bit", "8bit", "", "binary"].includes(encoding))
+    return body;
+  const bytes = decodeBodyBytes(body, encoding);
   try {
     const normalized = charset.toLowerCase().replace("windows-", "windows-").replace("iso-", "iso-");
     return new TextDecoder(normalized).decode(bytes);
@@ -7486,11 +7499,49 @@ var WebMailxService = class _WebMailxService {
   async getMessageSource(_accountId, _uid, _folderId) {
     return this.notImpl("getMessageSource");
   }
-  async getAttachment(_accountId, _uid, _attachmentId, _folderId) {
-    return this.notImpl("getAttachment");
+  /** The bytes of one attachment, base64 for the wire — the same shape the
+   *  desktop jsonrpc `getAttachment` case returns, because the same viewer
+   *  code consumes both.
+   *
+   *  2026-09-04 — Claude Code (Opus 5), at Bob's direction ("I tried opening
+   *  a pdf attachment on Android and it said 'opening' but nothing
+   *  happened"). This was a `notImpl` stub sitting immediately above a
+   *  comment explaining that Android opens attachments through the native
+   *  bridge "— getAttachment + base64 hand-off covers it". Both statements
+   *  were in the file at once, and the second was describing this method.
+   *  The viewer's Android branch does what that comment says: it calls
+   *  getAttachment for the bytes and hands them to
+   *  `_nativeBridge.openAttachment`. The throw landed in the chip's catch,
+   *  which posts a banner and restores the label — so from the phone it read
+   *  as "Opening…" and then nothing. Log line, verbatim:
+   *  `Couldn't open "…rev159-PRIVATE-DRAFT.pdf": Not implemented on Android:
+   *  getAttachment`.
+   *
+   *  `attachmentId` is the chip's id, which getMessage assigns as the index
+   *  into this same parser's attachment list — so the two must stay the same
+   *  parse. Re-reading the body rather than caching it keeps that true even
+   *  if the message is re-fetched between opening it and tapping the chip. */
+  async getAttachment(accountId, uid, attachmentId, folderId) {
+    const envelope = this.db.getMessageByUid(accountId, uid, folderId);
+    if (!envelope)
+      throw new Error("Message not found");
+    const raw = await this.syncManager.fetchMessageBody(accountId, envelope.folderId, envelope.uid);
+    if (!raw)
+      throw new Error("Message body isn't downloaded yet \u2014 open the message, then try the attachment again.");
+    const parsed = parseEmailSource(new TextDecoder().decode(raw));
+    const att = parsed.attachments?.[attachmentId];
+    if (!att)
+      throw new Error(`Attachment ${attachmentId} not found in this message`);
+    return {
+      content: base64FromBytes(att.content),
+      contentType: att.contentType || "application/octet-stream",
+      filename: (att.filename || "attachment").replace(/"/g, "")
+    };
   }
   // Android opens attachments via the native bridge (_nativeBridge.openAttachment),
-  // not this service path — getAttachment + base64 hand-off covers it.
+  // which the viewer reaches directly with the bytes getAttachment returns
+  // above; there is no service-side "save it and ask the OS to open it" on a
+  // phone.
   async openAttachment(_accountId, _uid, _attachmentId, _folderId) {
     return this.notImpl("openAttachment");
   }