Forward a message as an attachment

Forwarding quoted the original into a new message, which is the right
thing for passing on something to be read and the wrong thing for passing
on something to be looked at. Quoting rewrites the body, drops the
headers, and re-parents the attachments, so a bounce, a phishing report or
anything else where the message itself is the evidence arrived altered.

Forward as attachment sends the message whole, as a message/rfc822 part.
It costs no upload at all: a message's own blobId is its RFC822 blob and
already lives in the account, so this goes through the same by-reference
path as attach-from-Files and a 40 MB message attaches as fast as a small
one.

It is in the message's own menu, the list's right-click menu, and the
overflow on the reply strip at the foot of a thread, which is the one a
thumb finds on a phone.

Two things fixed on the way, both exposed rather than introduced by this.

The filename rule was subject.replace(/[^\w.-]+/g, "_"), and \w without
the u flag is ASCII: every character of a Russian, Japanese or Chinese
subject failed the class, so those messages downloaded as a row of
underscores. What is actually unsafe in a filename is much shorter than
"not ASCII" -- path separators, the names Windows reserves, the control
range -- so the rule now keeps letters from any script and drops only
those. It lives in one place and the .eml download uses it too.

And the composer's attachment chip set overflow/text-overflow on a span,
where neither does anything, so the name never truncated and the size ran
on after it on the same line. Only long names showed it, which is every
.eml named from a subject.

web/src/lib/emlName.ts

@@ -0,0 +1,50 @@
+/**
+ * A filename for a message saved or attached as `.eml`.
+ *
+ * The rule this replaces was `subject.replace(/[^\w.-]+/g, "_")`, and `\w`
+ * without the `u` flag is ASCII: every character of a Russian, Japanese or
+ * Chinese subject failed the class, so those messages downloaded as a row of
+ * underscores. ihasmail ships in nine languages besides English, so the
+ * subjects it handled worst were most of the world's.
+ *
+ * What is actually unsafe in a filename is a much shorter list than "not
+ * ASCII": the path separators, the characters Windows reserves, and the
+ * control range. Everything else is a letter to somebody.
+ *
+ * The test is written by code point rather than as a character class because
+ * the escaping in one of those is its own small trap, and this says plainly
+ * what it means.
+ */
+
+/** Reserved on Windows, or a path separator. */
+const RESERVED = '<>:"/\\|?*';
+
+function unsafe(ch: string): boolean {
+  const c = ch.codePointAt(0) ?? 0;
+  // C0 controls, and DEL.
+  if (c < 0x20 || c === 0x7f) return true;
+  return RESERVED.includes(ch);
+}
+
+/**
+ * Long enough to stay recognisable, short enough to survive a 255-*byte* limit
+ * once a CJK subject is three bytes a character.
+ */
+const MAX = 80;
+
+/** The stem only, so a caller can put another extension on it. */
+export function sanitizeFilename(subject: string | null | undefined): string {
+  const kept = [...(subject ?? "")].filter((ch) => !unsafe(ch)).join("");
+  return kept
+    // Whitespace becomes an underscore rather than being kept: it is what the
+    // previous rule did, and it saves a quoting question in a shell later.
+    .replace(/\s+/g, "_")
+    .slice(0, MAX)
+    // Windows refuses a name ending in a dot or a space, and a leading dot
+    // hides the file on Unix. Neither is worth inheriting from a subject.
+    .replace(/^[.\s_]+|[.\s_]+$/g, "");
+}
+
+export function emlFilename(subject: string | null | undefined): string {
+  return `${sanitizeFilename(subject) || "message"}.eml`;
+}