jcoffey-dev
0db795371e
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.
51 lines
1.9 KiB
TypeScript
51 lines
1.9 KiB
TypeScript
/**
|
|
* 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`;
|
|
}
|