void 0.26.1 → 0.28.0

package/dist/{mime-DxCznlJq.mjs → mime-srOklVVv.mjs}

@@ -1,3 +1,4 @@
+import { n as bytesToBase64 } from "./base64-DVrOndmI.mjs";
 import { validate } from "email-validator";
 //#region src/runtime/email/mime.ts
 /**
@@ -10,29 +11,10 @@ import { validate } from "email-validator";
 /** Encoded outbound MIME ceiling, separate from the 10 MiB inbound limit. */
 const MAX_MESSAGE_BYTES = 5242880;
 /**
-* Upper bound on the TOTAL attachment bytes `normalizeEmail` will materialize.
-*
-* Base64 expands by `ceil(n / 3) * 4`, so an attachment set larger than three
-* quarters of `MAX_MESSAGE_BYTES` cannot fit in a message that passes the
-* check at the end of `buildMime` no matter how small everything else is.
-* `buildMime` remains the authority on the final size — this bound only stops
-* `normalizeEmail` from materializing, and then expanding, bytes already known
-* not to fit.
-*
-* It has to be charged here because that final check comes far too late to
-* help. Measured peak live memory is about 10x the attachment bytes (8 MiB in
-* gives 83 MiB live) once the normalized copy, the base64 binary string, the
-* 76-column slices, the joins, `rawText` and its `TextEncoder.encode` are all
-* resident at once. Against a 128 MB isolate ceiling, a set over roughly
-* 12 MiB terminates the isolate rather than returning the `MIME_ERROR` the
-* docs promise for an oversize payload.
-*
-* This is a developer-experience guardrail, NOT the security boundary.
-* Attachments come from the app's own code, never from a remote sender, and
-* the platform proxy already caps the base64 length before decoding and the
-* raw length after. What this buys is a precise, catchable failure at the call
-* that went wrong, instead of a dead isolate with nothing a caller could act
-* on.
+* Total attachment bytes `normalizeEmail` will materialize: base64 of more
+* than 3/4 of `MAX_MESSAGE_BYTES` cannot fit. Charged before each copy so an
+* oversize set fails with `MIME_ERROR` instead of exhausting the isolate;
+* `buildMime`'s final size check stays authoritative.
 */
 const MAX_ATTACHMENT_BYTES_TOTAL = Math.floor(MAX_MESSAGE_BYTES * 3 / 4);
 /** Maximum serialized size of app-defined top-level MIME fields. */
@@ -47,33 +29,24 @@ function rejectCRLF(field, value) {
 	}
 }
 /**
-* Refuse any other C0 control or DEL in a value that is rendered VERBATIM
-* into a header — an attachment's filename, media type and Content-ID.
-* `rejectCRLF` is enough for a value `encodeWord` renders (the subject, a
-* custom header value, a display name): anything outside printable ASCII
-* sends the whole value into base64, so a control never reaches the wire.
-* These three go through `quoteParam` or straight into the line, so a
-* control would reach the wire for the receiving MTA to refuse.
-*
-* RFC 5322 §3.2.4 `qtext` is printable US-ASCII less `"` and `\`; a
-* control inside a quoted-string is `obs-qtext`, which §4 says MUST NOT be
-* generated. HTAB is deliberately NOT refused: `quoted-string` is
-* `DQUOTE *([FWS] qcontent) [FWS] DQUOTE` and `FWS` is built from `WSP`
-* (SP / HTAB), so a tab between characters is folding white space exactly
-* as a space is — and `obs-NO-WS-CTL`, the RFC's own list of the controls
-* that used to be `qtext`, leaves %d9 out. The same set is illegal in an
-* RFC 2045 §5.1 `token` (no CTLs) and an RFC 5322 §3.6.4 `msg-id`
-* (`dot-atom-text`), so one rule serves the media type and the Content-ID.
-*
-* The message names the code point and never echoes the value, as
-* `validateAddressParts` does. Runs AFTER the filename's length bound, so
-* the scan is over a value already known to fit a line.
+* Index of the first C0 control other than HTAB, or DEL; -1 when there is
+* none. HTAB is folding whitespace (RFC 5322 §3.2.2).
 */
-function rejectControls(field, value) {
+function indexOfControl(value) {
 	for (let i = 0; i < value.length; i++) {
 		const c = value.charCodeAt(i);
-		if (c < 32 && c !== 9 || c === 127) throw new MimeError("MIME_ERROR", `${field} contains a control character (U+${c.toString(16).toUpperCase().padStart(4, "0")}).`);
+		if (c < 32 && c !== 9 || c === 127) return i;
 	}
+	return -1;
+}
+/**
+* Refuse a control in a value rendered verbatim into a header (an
+* attachment's filename, media type and Content-ID). Names the code point,
+* never the value.
+*/
+function rejectControls(field, value) {
+	const i = indexOfControl(value);
+	if (i !== -1) throw new MimeError("MIME_ERROR", `${field} contains a control character (U+${value.charCodeAt(i).toString(16).toUpperCase().padStart(4, "0")}).`);
 }
 /** RFC 2045 §5.1 `tspecials`: what a `token` may not contain besides SPACE and CTLs. */
 const TSPECIALS = "()<>@,;:\\\"/[]?=";
@@ -82,33 +55,10 @@ function isTokenChar(c) {
 	return c > 32 && c < 127 && !TSPECIALS.includes(String.fromCharCode(c));
 }
 /**
-* Refuse an attachment media type that does not parse as RFC 2045 §5.1
-* `type "/" subtype *(";" parameter)`.
-*
-* `rejectControls` answers only for CTLs, and `buildAttachmentPart` writes
-* the value verbatim ahead of its own `; name="…"`, so an unterminated
-* quote such as `text/plain; x="` would swallow the builder's `name`
-* parameter as the value of `x`.
-*
-* The grammar is the RFC's, read as a generator: a `token` is printable
-* US-ASCII less SPACE and `tspecials`; a `value` is a `token` or a
-* quoted-string, whose content is anything but a bare `"` or `\` (the same
-* rule `quoteParam` renders `name="…"` by, so a caller's quoted value may
-* carry what the builder's own already does). Optional WSP is admitted on
-* either side of `;` — the RFC 822 implicit LWSP every parser accepts and
-* the form HTTP's `Content-Type` writes — and nowhere else: `text/ plain`,
-* a trailing `;`, and an RFC 822 comment are refused rather than repaired.
-* Two parameters are also refused on their meaning: a `name`, because the
-* builder appends `name="<filename>"` and RFC 6838 §4.3 makes it "an error
-* for a specific parameter to be specified more than once"; and by that
-* same sentence any attribute given twice, compared case-insensitively as
-* §5.1 says attributes match. Type and subtype are kept as given — matching
-* is case-insensitive, so `TEXT/PLAIN` is legal and renders unchanged.
-*
-* One pass, no backtracking, and the only allocation is one lower-cased
-* attribute per parameter for the duplicate check, which is why this runs
-* AFTER the value's length bound. The message names the rule and never
-* echoes the value.
+* Refuse a media type that is not RFC 2045 §5.1 `type "/" subtype *(";"
+* parameter)`: it is written verbatim before the builder's `name=`, so an
+* unterminated quote would swallow it. WSP is allowed only around `;`. A
+* `name` parameter or a repeated attribute is refused (RFC 6838 §4.3).
 */
 function validateMediaType(field, value) {
 	const syntax = () => new MimeError("MIME_ERROR", `${field} is not a valid media type (RFC 2045 §5.1: type/subtype, then ; attribute=value parameters).`);
@@ -160,34 +110,9 @@ function isAtext(c) {
 	return c >= 48 && c <= 57 || c >= 65 && c <= 90 || c >= 97 && c <= 122 || ATEXT_SYMBOLS.includes(String.fromCharCode(c));
 }
 /**
-* Refuse an attachment Content-ID that would not render as one RFC 5322
-* §3.6.4 `msg-id`.
-*
-* `rejectControls` answers only for CTLs, and `buildAttachmentPart` writes
-* the value verbatim — adding `<` and `>` unless the value already starts
-* with `<` — so a malformed id would reach the receiver and break the
-* `cid:` reference.
-*
-* The grammar is the RFC's, read as a generator, with two deliberate
-* differences. An `msg-id` is `"<" id-left "@" id-right ">"`, each side a
-* `dot-atom-text` (§3.2.3: `1*atext *("." 1*atext)`, so no leading,
-* trailing or doubled dot — the strict form; `obs-id-left`/`obs-id-right`
-* are §4 obsolete syntax, which MUST NOT be generated); `no-fold-literal`
-* (`[…]` for `id-right`) is left out. First difference: the `@` and its
-* right side are OPTIONAL. RFC 2392 §2 resolves a `cid:` URL by wrapping
-* its body in `<` `>` and matching that against `Content-ID`, so an id
-* without `@` — the documented `contentId: 'logo'` + `cid:logo` — is what
-* every client already resolves, and the domain that would make it a
-* proper `msg-id` adds nothing a reference could use. Second: the angle
-* brackets are optional too, because the builder has always added them
-* around a bare id; given, they must be one pair around the whole value.
-*
-* Refused, then: whitespace of any kind, a second `@`, `<` or `>` anywhere
-* but as that one pair, `"`, `(`, `)`, `,`, `;`, `:`, `\`, `[`, `]`,
-* anything non-ASCII, and the empty string.
-*
-* One pass, no allocation, which is why this runs AFTER the value's length
-* bound. The message names the rule and never echoes the value.
+* Refuse a Content-ID that would not render as an RFC 5322 §3.6.4 `msg-id`
+* of strict `dot-atom-text`. Unlike `msg-id`, the `@` part and the angle
+* brackets are optional: `cid:logo` resolves against `<logo>` (RFC 2392).
 */
 function validateContentId(field, value) {
 	const syntax = () => new MimeError("MIME_ERROR", `${field} is not a valid Content-ID (RFC 5322 §3.6.4 msg-id: an identifier of atext, "." and "@", optionally in one pair of angle brackets).`);
@@ -255,37 +180,10 @@ function fieldErrorCode(field) {
 	return "MIME_ERROR";
 }
 /**
-* Validate one parsed address (and its display name, when there is one),
-* throwing a `MimeError` for `field` on anything undeliverable. Exported so
-* the inbound proxy's `forward(to)` and hand-built `reply()` refuse a bare
-* address by the same rule `sendEmail` applies to its `to`.
-*
-* The address rule is `email-validator`, and nothing else. It is also the
-* platform router's rule (`isValidEmailAddress` in the proxy's
-* `email-router.ts`), so there is exactly ONE address syntax in the tree:
-* an action the framework records is never dropped by the router for its
-* shape, and a test harness never captures as a success what the managed
-* deployment would lose.
-*
-* What it enforces: at most 254 characters in total; an ASCII dot-atom
-* local part of at most 64 characters (RFC 5322 §3.2.3 `atext`, dots only
-* between atoms — no quoted local part, no whitespace, no control, no
-* special); a dotted domain of ASCII labels of at most 63 characters each,
-* with a TLD that starts with a letter and has at least two characters; so
-* `user@localhost`, `x@y` and a raw IDN or SMTPUTF8 address are refused
-* (an IDN domain is accepted as punycode, `xn--…`). ASCII-only makes
-* octets and characters the same thing, so the RFC 5321 §4.5.3.1 octet
-* limits are the package's length checks; the 64 is also what caps the
-* default `<slug>+noreply@` sender (`VALID_SLUG` in `runtime/email.ts`,
-* `MAX_SLUG_LENGTH` = `64 - 8` in `cli/project-slug.ts` and the API). One
-* known quirk, pinned in the tests rather than worked around: the FIRST
-* character of the local part may not be a backtick, while any later one
-* may.
-*
-* `MAX_ADDRESS_LENGTH` still runs first, on the raw string, so the scan is
-* bounded before anything reads the address; the package's own 254 check
-* runs before its regex for the same reason. The message never echoes the
-* address: it may hold a control character, and naming the rule is enough.
+* Validate one parsed address and optional display name, throwing a
+* `MimeError` for `field`. The address rule is `email-validator`, the one
+* the platform router applies, so a recorded action is never dropped for its
+* shape. The message never echoes the address.
 */
 function validateAddressParts(field, email, name) {
 	if (email.length > 320) throw new MimeError(fieldErrorCode(field), `${field}: address is ${email.length} characters, over the 320-character limit.`);
@@ -297,25 +195,9 @@ function validateAddressParts(field, email, name) {
 	}
 }
 /**
-* Undo the quoted-pairs in the content of a quoted display name: `\x` →
-* `x` for any `x` (RFC 5322 §3.2.4 — `qtext` excludes `"` and `\`, so a
-* quoted-string carries either only as a quoted-pair). The parsed name is
-* the RAW text `formatAddress` will quote and escape again, so leaving the
-* pairs in place would escape them twice. Only the quoted branch
-* of `parseAddress` calls this; a backslash in an unquoted name is a
-* character like any other, as it is in the object form.
-*
-* NOT `text.replace(/\\(.)/g, '$1')`: a global-regex replacement holds one
-* part per match before it builds the result, about 60 bytes each, and
-* nothing bounds this name before it runs — the quoted-string line guard
-* in `validateAddressParts` needs the DECODED name, and a non-ASCII name is
-* never bounded at all. Measured, 10 MiB of `\"` pairs peaked at 307 MB of
-* heap that way and terminated a 128 MB isolate; this shape peaks at 49 MB.
-* Same discipline as `to7bitBody`: one counting pass, a buffer of exactly
-* the output size, one fill, and one chunked `codeUnitsToString`.
-* The common case — no backslash at all — is one scan and no allocation.
-* The regex that admits the text guarantees every backslash is followed by
-* a character, so the fill never reads past the end.
+* Undo quoted-pairs (`\x` → `x`) in a quoted display name so `formatAddress`
+* escapes it once. A counting pass and an exact buffer, not a global-regex
+* replace, which allocates per match on an unbounded name.
 */
 function unquotePairs(text) {
 	const first = text.indexOf("\\");
@@ -372,22 +254,14 @@ function countRecipients(value) {
 	if (!value) return 0;
 	return Array.isArray(value) ? value.length : 1;
 }
-/**
-* Keeps the `exceeds Cloudflare limit of <N> bytes` tail that `buildMime`'s
-* own size error already uses, so the documented shape — and any caller
-* matching on it — holds for both paths.
-*/
+/** Same `exceeds Cloudflare limit of <N> bytes` tail as `buildMime`'s size error. */
 function attachmentsTooLargeError(bytes) {
 	return new MimeError("MIME_ERROR", `email: attachment size ${bytes} bytes exceeds Cloudflare limit of ${MAX_ATTACHMENT_BYTES_TOTAL} bytes.`);
 }
 /**
-* Size of `content` WITHOUT materializing it.
-*
-* A string reports its UTF-16 `length`, which is a sound LOWER bound on its
-* UTF-8 byte length — every code unit encodes to at least one byte — so this
-* can never reject a string that would have fit; the exact length is charged
-* after the encode. Anything else reports 0 and is left to `toBytes` to reject
-* by type.
+* Size of `content` without materializing it. A string's `length` is a lower
+* bound on its UTF-8 size; an unsupported type reports 0 for `toBytes` to
+* reject.
 */
 function declaredSize(content) {
 	if (content instanceof Uint8Array) return content.byteLength;
@@ -493,22 +367,13 @@ async function normalizeEmail(opts) {
 	};
 }
 /**
-* RFC 2047 §2 caps an encoded-word at 75 characters *including* the
-* `=?UTF-8?B?` prefix (10) and the `?=` suffix (2). That leaves 63
-* characters of base64, and base64 spends 4 characters per 3 input
-* bytes, so 45 source bytes is the largest payload that fits — 48 would
-* need 64.
+* RFC 2047 §2: a 75-character encoded-word less `=?UTF-8?B?` and `?=` leaves
+* 63 characters of base64, so 45 source bytes.
 */
 const ENCODED_WORD_PAYLOAD_BYTES = 45;
 /**
-* RFC 2047 encoded-word for non-ASCII text in headers (UTF-8, base64).
-*
-* Text longer than one word's payload becomes several encoded-words
-* separated by a space, which `foldHeader` turns into CRLF + SPACE
-* wherever a line would otherwise overrun (RFC 2047 §6.2: whitespace
-* between adjacent encoded-words is dropped on decode either way). This
-* keeps each word under §2's 75-character ceiling and a long subject or
-* display name under RFC 5322 §2.1.1's 998-octet line limit.
+* RFC 2047 B encoded-words for non-ASCII header text, space-separated so
+* `foldHeader` can fold between them.
 */
 function encodeWord(text) {
 	if (ASCII_PRINTABLE.test(text)) return text;
@@ -518,7 +383,7 @@ function encodeWord(text) {
 	const words = [];
 	const flush = () => {
 		if (length > 0) {
-			words.push(`=?UTF-8?B?${base64(pending.subarray(0, length))}?=`);
+			words.push(`=?UTF-8?B?${bytesToBase64(pending.subarray(0, length))}?=`);
 			length = 0;
 		}
 	};
@@ -532,17 +397,8 @@ function encodeWord(text) {
 	return words.join(" ");
 }
 /**
-* RFC 5322 §3.2.3, verbatim:
-*
-*     specials = "(" / ")" / "<" / ">" / "[" / "]" / ":" / ";" / "@" /
-*                "\" / "," / "." / DQUOTE
-*
-* A display name is a §3.2.5 `phrase = 1*word`, `word = atom /
-* quoted-string`, and `atext` is everything printable EXCEPT these, so an
-* ASCII name containing any of them must be rendered as one quoted-string.
-* The class below lists the thirteen in the RFC's order so it can be checked
-* against the production by eye. `.` matters: an unquoted `Dr. Smith` is
-* `obs-phrase` (§4.1), which §4 says MUST NOT be generated.
+* RFC 5322 §3.2.3 `specials`, in the RFC's order: an ASCII display name with
+* any of them must be quoted (an unquoted `Dr. Smith` is obsolete syntax).
 */
 const RFC5322_SPECIALS = /[()<>[\]:;@\\,."]/;
 function formatAddress(addr) {
@@ -555,25 +411,10 @@ function formatAddressList(addrs) {
 	return addrs.map(formatAddress).join(", ");
 }
 /**
-* Soft-fold a long header line. Fold points, strongest first: address-list
-* separators (a `, ` outside any double-quoted string), then any remaining
-* unquoted whitespace inside a part. A naive `split(/, /)` would split
-* inside `"Smith, John"`, corrupting quoted display names, and folding only
-* between whole parts is not enough — one recipient carrying a long encoded
-* display name, or a `References:` run of message IDs, is a single part
-* that can blow past RFC 5322 §2.1.1's 998-octet hard limit on its own.
-*
-* RFC 2047 §2 limits any header line carrying an encoded-word to 76
-* characters; RFC 5322 §2.1.1 makes 78 a SHOULD and 998 a MUST. Folding at
-* 76 satisfies all three. A comma always stays on the line it terminates.
-* A token longer than the budget still gets its own line, which is the
-* best a WSP-only fold rule allows (§3.2.2 permits folding only at WSP).
-*
-* One pass, and the only thing kept per input character is the folded
-* output itself: each finished line is one flat string in `lines`. Any
-* per-token allocation (a slice array, token objects, `out +=`) costs about
-* 130 bytes of heap per token, so a legal 3 MB subject of one-letter words
-* would terminate a 128 MB isolate even though the message fits.
+* Soft-fold a header at 76 columns (RFC 2047 §2): at `, ` outside quotes
+* first, then at unquoted whitespace. A token longer than a line keeps its
+* own line, since RFC 5322 folds only at WSP. One pass that keeps only the
+* output; per-token allocation would exhaust the isolate on a large subject.
 */
 function foldHeader(name, value) {
 	const line = `${name}: ${value}`;
@@ -653,40 +494,20 @@ const MAX_LINE_OCTETS = 998;
 /** ` filename="` + `"`: the shortest line a quoted filename parameter can fold onto. */
 const QUOTED_FILENAME_LINE_OVERHEAD = 12;
 /**
-* ` ` + `;`: the shortest line an attachment's media type can fold onto,
-* the whole value taken as one token. `foldHeader` would split a value
-* of several parameters at their spaces, so this bound is exact for the
-* one-token media type every attachment carries in practice and
-* conservative for a run of parameters that together pass the line
-* limit; that is accepted, because the alternative — find the fold points
-* first — is the scan this bound exists to run ahead of.
+* ` ` + `;`: the shortest line the media type can fold onto as one token
+* (conservative for several parameters).
 */
 const CONTENT_TYPE_LINE_OVERHEAD = 2;
-/**
-* `Content-ID: `: the only line an attachment's Content-ID can sit on. The
-* value is one token — `<id>` — so `foldHeader` cannot fold it onto a
-* continuation line the way it can a media type, and the field name is
-* part of what the id must fit beside. Exact, not conservative: the `<`
-* and `>` the builder adds around a bare id are charged at the call.
-*/
+/** `Content-ID: `: the id is one token and cannot fold off this line. */
 const CONTENT_ID_LINE_OVERHEAD = 12;
 /** ` "` + `"`: the shortest line a quoted display name can fold onto. */
 const QUOTED_NAME_LINE_OVERHEAD = 3;
 /** `:` alone: the shortest line a header name can sit on, its value folded onto the next. */
 const HEADER_NAME_LINE_OVERHEAD = 1;
 /**
-* First line of `text` that exceeds the octet limit, if any.
-*
-* Every line is scanned, not just the top header block: a multipart part's
-* own headers (`Content-Disposition: …; filename="…"`) live inside the body
-* and are just as unfoldable. Body content cannot trip this — text is
-* quoted-printable re-encoded above 990 octets and base64 is emitted at a
-* fixed width — so a hit is always a header.
-*
-* One pass over the string, counting UTF-8 octets per CRLF-delimited line,
-* with NO allocation: a `split(CRLF)` would hold one substring per line, and
-* a legal body of pasted logs is millions of lines. Only a CRLF pair ends a
-* line; a bare CR or LF is content.
+* First CRLF-delimited line over the octet limit, counted in UTF-8 without
+* allocating. Every line is scanned because part headers live in the body;
+* encoded body content never trips it.
 */
 function findOverlongLine(text) {
 	let index = 0;
@@ -716,24 +537,20 @@ function findOverlongLine(text) {
 		octets
 	} : void 0;
 }
-/**
-* Escape a value for a quoted-string parameter (RFC 2045 §5.1 value, whose
-* quoted-string comes from RFC 5322 §3.2.4).
-*
-* `qtext` excludes both `\\` and `"`, so each may appear only as a
-* quoted-pair: a raw trailing backslash would escape the closing quote, and
-* a conformant parser drops every other raw backslash.
-*
-* Backslash first, then quote — the other order would double-escape.
-*/
+/** Escape `\` and `"` as quoted-pairs (RFC 5322 §3.2.4), backslash first. */
 function quoteParam(value) {
 	return value.replace(/\\/g, "\\\\").replace(/"/g, "\\\"");
 }
-function base64(bytes) {
-	return btoa(codeUnitsToString(bytes));
+/** `<prefix>_<base36 time><16 random hex>`. */
+function newId(prefix) {
+	const bytes = /* @__PURE__ */ new Uint8Array(8);
+	crypto.getRandomValues(bytes);
+	let hex = "";
+	for (const b of bytes) hex += b.toString(16).padStart(2, "0");
+	return `${prefix}_${Date.now().toString(36)}${hex}`;
 }
 function base64Wrapped(bytes) {
-	const encoded = base64(bytes);
+	const encoded = bytesToBase64(bytes);
 	const lines = [];
 	for (let i = 0; i < encoded.length; i += 76) lines.push(encoded.slice(i, i + 76));
 	return lines.join(CRLF);
@@ -797,14 +614,9 @@ function codeUnitsToString(units) {
 	return s;
 }
 /**
-* Whether a body must be quoted-printable encoded: anything outside
-* printable ASCII, or any line longer than 990 characters (RFC 5322 §2.1.1
-* makes 998 octets the hard limit). Only LF and CRLF end a line; a bare CR
-* is a control character like any other and forces the encoding.
-*
-* One pass over the string with NO allocation: a `replace`/`split` shape
-* holds a copy of the body plus one substring per line, and a legal 6 MB
-* body of millions of two-character lines needed about 100 MB that way.
+* Whether a body needs quoted-printable: anything outside printable ASCII
+* (a bare CR included) or a line over 990 characters. One pass without
+* allocation.
 */
 function needsQuotedPrintable(text) {
 	let lineLen = 0;
@@ -825,18 +637,9 @@ function needsQuotedPrintable(text) {
 	return false;
 }
 /**
-* The 7bit body: `text` with every bare LF widened to CRLF, and every CRLF
-* kept. Only called once `needsQuotedPrintable` has returned false, so every
-* character is printable ASCII, LF, or the CR of a CRLF — one byte each —
-* and a byte buffer is exact.
-*
-* NOT `text.replace(/\r?\n/g, CRLF)`: V8 builds a global-regex replacement
-* from a parts array that holds two or three slots per match, grown by
-* doubling, so that one line cost 144 MB of heap on a legal 6 MB body of
-* 3M lines and terminated a 128 MB isolate — the largest single allocation
-* in the whole build, for a body that renders to 9 MB. The buffer here is
-* the output size, known up front from one counting pass. A body that is
-* already CRLF-only (or has no line breaks) is returned as-is.
+* `text` with each bare LF widened to CRLF. Called only when every character
+* is one byte, so a counting pass sizes the buffer exactly; a global-regex
+* replace would allocate per line.
 */
 function to7bitBody(text) {
 	let bare = 0;
@@ -852,16 +655,8 @@ function to7bitBody(text) {
 	return codeUnitsToString(out);
 }
 /**
-* Lower bound on the octets `text` will occupy in the rendered message, in
-* one pass over the string and with NO allocation. Every UTF-8 byte yields at
-* least one octet on either body path — the 7bit path copies bytes and only
-* ever widens a bare LF to CRLF; the quoted-printable path emits each
-* non-ASCII byte as `=XX` (3 octets) and every other byte as itself, and its
-* soft breaks only add. So `ascii + 3 * nonAscii` can never overshoot the
-* real size, which keeps a false rejection impossible; `buildMime`'s final
-* check remains the authority. `TextEncoder.encode` would give the same count
-* but at the price of a full copy, which is exactly the allocation this
-* bound exists to avoid.
+* Lower bound on `text`'s rendered octets, without allocating: ASCII is at
+* least 1 octet and each non-ASCII UTF-8 byte is `=XX`.
 */
 function minBodyOctets(text) {
 	let octets = 0;
@@ -913,7 +708,7 @@ function buildAttachmentPart(att) {
 function makeBoundary(prefix) {
 	const bytes = /* @__PURE__ */ new Uint8Array(16);
 	crypto.getRandomValues(bytes);
-	return `=_void_${prefix}_${base64(bytes).replace(/[+/=]/g, "")}`;
+	return `=_void_${prefix}_${bytesToBase64(bytes).replace(/[+/=]/g, "")}`;
 }
 function wrapMultipart(type, parts) {
 	const boundary = makeBoundary(type);
@@ -939,29 +734,10 @@ const RESERVED_HEADERS = /* @__PURE__ */ new Set([
 	"content-disposition"
 ]);
 /**
-* Lower bound on the octets one header VALUE occupies once `encodeWord` (or
-* `formatAddress`, for a display name) and `foldHeader` have rendered it, in
-* one pass over the string and with NO allocation.
-*
-* `encodeWord` leaves a value alone when every character is printable ASCII
-* and otherwise B-encodes ALL of it, so the two paths need different terms:
-*
-* - Plain: every character is at least one octet, EXCEPT whitespace.
-*   `foldHeader` re-joins a long value from its non-WSP tokens, so a run of
-*   spaces or tabs collapses to one, and a bound that charged them could
-*   reject a message that fits. Only the non-WSP characters count.
-* - Encoded: each RFC 2047 word carries at most `ENCODED_WORD_PAYLOAD_BYTES`
-*   (45) UTF-8 bytes as base64 — `ceil(n / 3) * 4 >= 4n / 3` octets — inside
-*   12 octets of `=?UTF-8?B?` and `?=`, so there are at least `floor(n / 45)`
-*   words' worth of framing. Whitespace inside the value is base64 like any
-*   other byte; only the single separators between words fold.
-*
-* Folding (`foldHeader`) can only ADD octets beyond that — a `CRLF SP` per
-* line — and quoting a display name (`formatAddress`) adds the quotes and
-* escapes, so neither path can render fewer octets than this returns.
-* Measured, the encoded bound is 96% of the rendered size for CJK, where the
-* real cost is 5 octets per character; a UTF-16 `length` would have counted
-* 1 and let the isolate die on a header five times over the limit.
+* Lower bound on one rendered header value, without allocating. Printable
+* ASCII counts its non-WSP characters (folding may collapse WSP runs);
+* anything else is B-encoded whole, at least 4/3 of its UTF-8 bytes plus 12
+* octets of framing per 45-byte word.
 */
 function minHeaderValueOctets(value) {
 	let utf8 = 0;
@@ -996,18 +772,9 @@ function minAddressOctets(addr) {
 	return addr.email.length + (addr.name ? minHeaderValueOctets(addr.name) : 0);
 }
 /**
-* Lower bound on the octets of a value rendered VERBATIM — never through
-* `encodeWord` — into a header `foldHeader` may still fold: `In-Reply-To`,
-* `References`, and an attachment part's `Content-Type` media type and
-* `Content-ID`. Every non-WSP UTF-16 code unit is at least one octet of
-* UTF-8; a WSP run may collapse to a single space when the line folds, so
-* none is charged. The `<>` around a Content-ID and the fold's `CRLF SP`
-* only add.
-*
-* `minHeaderValueOctets` cannot stand in here: a non-ASCII value sends it
-* down the encoded-word formula (4.8 octets per CJK character) while these
-* values render as raw UTF-8 (3), so it would overshoot and could reject a
-* message that fits.
+* Lower bound on a value rendered verbatim (threading ids, media type,
+* Content-ID): one octet per non-WSP code unit. `minHeaderValueOctets` would
+* overshoot, since these are raw UTF-8, not encoded-words.
 */
 function minVerbatimOctets(value) {
 	let octets = 0;
@@ -1018,94 +785,24 @@ function minVerbatimOctets(value) {
 	return octets;
 }
 /**
-* Octets every attachment part costs before any of its values: what
-* `wrapMultipart`, `renderPart` and `buildAttachmentPart` emit for a part
-* whose filename, media type, disposition and content are all empty. Each
-* term is emitted verbatim on every path — `foldHeader` returns a short
-* line as-is and re-joins a long one from its tokens with at least one
-* space between them, so the space after `Name:` and the one after `;` are
-* floors, not counts — and a fold's `CRLF SP` only adds. The boundary's
-* random suffix is left out: `makeBoundary` strips `+`, `/` and `=`, so it
-* has no provable minimum, and `mixed` is the shortest prefix an attachment
-* part can sit under.
+* Framing every attachment part costs with empty values. The random boundary
+* suffix has no provable minimum, so it is not counted.
 */
 const ATTACHMENT_PART_MIN_OCTETS = 117;
 /**
-* Cap on the attachment COUNT, checked against the raw list in
-* `normalizeEmail` before a single entry is normalized.
-*
-* Every part costs at least `ATTACHMENT_PART_MIN_OCTETS` of framing plus
-* its filename twice, and `normalizeAttachment` refuses an empty filename,
-* so the size projection in `buildMime` charges a part at least 119 octets
-* and refuses one more part than this whatever else the message holds.
-* That projection runs only after `normalizeEmail` has normalized EVERY
-* entry, and `MAX_ATTACHMENT_BYTES_TOTAL` cannot bound that loop for a
-* zero-byte attachment — its running total never advances — while the
-* normalized copy (the object, a fresh `Uint8Array`, the `TextEncoder`
-* that made it) costs about 275 bytes of live heap per entry. Measured, 2M
-* empty attachments terminated a 128 MB isolate in 0.3 s instead of
-* returning `MIME_ERROR`; this many normalize in 24 MB and are then refused
-* by the post-render size check under the same ceiling.
-*
-* Derived, not chosen: it is exactly the largest count the projection can
-* admit, so this cannot reject a message that would have been accepted, and
-* `buildMime` remains the authority on the final size. Same class as
-* `MAX_ATTACHMENT_BYTES_TOTAL` — a developer-experience guardrail on the
-* app's own input, not the security boundary.
+* Cap on the attachment count, checked before any entry is normalized:
+* zero-byte entries never advance the byte total. It is the most parts
+* `buildMime`'s size projection can admit, so it refuses nothing that fits.
 */
 const MAX_ATTACHMENTS = Math.floor(MAX_MESSAGE_BYTES / 119);
-/**
-* Octets every custom header costs around its value: the `: ` after the
-* name and the CRLF that ends its line. Exact, not a floor, once the name
-* is counted: `buildMime` renders each non-reserved custom header through
-* `foldHeader`, which emits the name verbatim, then `: ` — or, when the
-* value's first token does not fit beside the name, `:` CRLF SP, which is
-* more — and `join(CRLF)` ends every header line, a custom header never
-* being the last of the block (the body part's own headers follow it).
-*/
+/** `: ` and the CRLF around a custom header value; exact once the name is counted. */
 const CUSTOM_HEADER_FRAMING_OCTETS = 4;
 /**
-* Lower bound on the octets of every header `buildMime` renders from
-* caller-supplied values: `Subject`, the custom headers, the addresses in
-* `From`, `To`, `Cc` and `Reply-To`, the `In-Reply-To` / `References` pair
-* `replyEmail` threads through (remote-sender controlled, up to the whole
-* inbound message), and each attachment part's `Content-Type`, `Content-ID`
-* and — twice, once per header it is rendered into — filename. `Bcc` is
-* never rendered and a reserved custom header is dropped, so neither is
-* counted — charging either could reject a message that fits. The fixed
-* `Name: ` and `CRLF` of the headers `buildMime` itself names — `Subject`,
-* the address lists, the threading pair — are omitted for the same reason
-* a lower bound may omit any term. They are NOT omitted where the caller
-* controls the name or the count, because there they can be the whole
-* message:
-*
-* - A custom header's name is rendered verbatim, and `normalizeEmail`
-*   bounds ONE name at under a kilobyte, not the sum, nor the count. With
-*   empty values the names and the `: ` CRLF around each are the entire
-*   size, and the framing is exact once the name is counted (see
-*   `CUSTOM_HEADER_FRAMING_OCTETS`), so charging both cannot reject a
-*   message that fits. Uncharged, 60k empty headers with 500-character
-*   names (a 30 MB message) would project to zero.
-* - An attachment part: `normalizeAttachment` bounds ONE filename at under
-*   a kilobyte, not the sum, and a message is free to carry any number of
-*   parts, so the filename and the framing every part is wrapped in are
-*   the whole size of a message of empty attachments. Measured, 50k
-*   zero-byte attachments with legal 986-character filenames rendered to
-*   106 MB — held three to four times over between the parts, their join,
-*   `rawText` and `raw` — and terminated a 128 MB isolate before the final
-*   size check could return `MIME_ERROR`.
-*
-* The header COUNT is deliberately not bounded here. Each header costs
-* at least five octets (a one-character name, `: `, CRLF), so the count
-* the projection can admit is finite, and past a few hundred thousand keys
-* the caller's own object — measured at about 74 bytes per key, before
-* `sendEmail` is called — is the dominant cost, which no check inside this
-* module can pre-empt. Rendering does add live heap per header (about
-* 150 bytes: two `Object.entries`, the `topHeaders` pair, the folded line),
-* so a legal message of 500k four-character headers still does not fit a
-* 128 MB isolate while one of 400k does; a bound on that would be the
-* framework's own number — the platform proxy bounds bytes, not headers —
-* and is left as a product decision rather than invented here.
+* Lower bound on every header rendered from caller values. Bcc and reserved
+* custom headers never render, and the fixed framing of Void's own headers
+* is omitted. A custom header's name and framing, and each attachment part's
+* framing and filename (twice), are charged: a message of many empty headers
+* or attachments is all framing.
 */
 function minHeaderOctets(email) {
 	let octets = minHeaderValueOctets(email.subject);
@@ -1127,7 +824,7 @@ function generateMessageId(fromEmail) {
 	const domain = fromEmail.split("@")[1] ?? "localhost";
 	const bytes = /* @__PURE__ */ new Uint8Array(12);
 	crypto.getRandomValues(bytes);
-	return `<${base64(bytes).replace(/[+/=]/g, "")}@${domain}>`;
+	return `<${bytesToBase64(bytes).replace(/[+/=]/g, "")}@${domain}>`;
 }
 /**
 * Build the raw RFC 5322 message body. Returns the message bytes plus the
@@ -1177,4 +874,4 @@ function buildMime(email) {
 	};
 }
 //#endregion
-export { parseAddress as a, normalizeEmail as i, MimeError as n, validateAddressParts as o, buildMime as r, MAX_MESSAGE_BYTES as t };
+export { newId as a, validateAddressParts as c, indexOfControl as i, MimeError as n, normalizeEmail as o, buildMime as r, parseAddress as s, MAX_MESSAGE_BYTES as t };