@blamejs/core 0.11.25 → 0.11.26

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.11.x
 
+- v0.11.26 (2026-05-20) — **`b.mail.server.submission` — CHUNKING / BDAT (RFC 3030).** The outbound submission listener now advertises and accepts the RFC 3030 BDAT (binary data) command, the chunked-upload alternative to DATA. Operators with large outbound payloads (attachments, MIME multipart bodies, encoded HTML) no longer pay the dot-stuffing cost of DATA; clients can stream chunks of arbitrary size and finalise with a `BDAT 0 LAST` (or `BDAT N LAST` for the final chunk). Mixing DATA + BDAT within one transaction is refused per RFC 3030 §3. Same `agent.handoff` contract — the body bytes arrive at the agent layer in their canonical SMTP form, no dot-stuffing applied (BDAT payloads are opaque). **Added:** *EHLO advertises `CHUNKING` + new `BDAT <chunk-size> [LAST]` command* — The EHLO 250-line list now includes `CHUNKING` (RFC 3030 §2.1). A new `BDAT` command handler accepts `BDAT <chunk-size> [LAST]` after MAIL FROM + RCPT TO; the server reads exactly `<chunk-size>` bytes from the socket — no dot-stuffing, no end-of-data marker — and acknowledges with `250 2.0.0 <octets> octets received`. Multiple BDAT chunks accumulate into the message body; the final chunk carries the `LAST` keyword and triggers the same agent-handoff path as DATA. A `BDAT 0 LAST` finalises an empty trailer when the last chunk's byte count is unknown in advance. · *Cumulative size cap honoured up-front* — `BDAT <large-size>` is refused with `552 5.3.4 BDAT cumulative size <total> exceeds maxMessageBytes (<cap>)` BEFORE the server begins reading bytes off the wire. A misconfigured client that pipelines `BDAT 999999999 LAST` and 1 GB of body is rejected at the command line, not after the byte stream lands. The collector bound on the receive side enforces the same cap as a backstop. · *Mid-segment payload drainage* — When `BDAT N LAST\r\n<payload>` arrives in one TCP segment (typical for pipelined small messages), the line-loop drains the post-`\r\n` bytes from the command buffer straight into the BDAT collector before returning. Any tail bytes after the BDAT chunk completes get re-fed as the next command. Operators get pipelining + chunking with no extra round-trip cost. **Security:** *BDAT state cleared on every STARTTLS upgrade* — Same threat model as CVE-2021-38371 (Exim) / CVE-2021-33515 (Dovecot): pre-handshake bytes a malicious peer pipelined MUST NOT reach the post-TLS state machine. The STARTTLS handler clears `inBdatChunk` / `bdatRemaining` / `bdatCollector` / `bdatTotalBytes` alongside the existing line-buffer + DATA-collector reset, so a smuggled `BDAT <n>` + body that lands before the TLS upgrade can't bleed into the encrypted transaction. · *Refusal on BDAT outside transaction* — BDAT before MAIL FROM / with zero RCPT returns `503 5.5.1` and does not enter chunk-collection mode. A misbehaving client that issues BDAT eagerly cannot leak state into the next transaction; the RSET reset path also clears all BDAT-side state. · *Pipelining race gate mirrors DATA* — If the operator's `recipientPolicy` is async and not all RCPT verdicts have resolved, BDAT returns `451 4.5.0 RCPT TO verdicts pending; reissue BDAT after recipient replies` — same shape as the DATA pipelining-race gate. The transaction never commits with a partially-resolved recipient set. **References:** [RFC 3030 (SMTP Service Extensions — CHUNKING / BDAT / BINARYMIME)](https://www.rfc-editor.org/rfc/rfc3030.html) · [RFC 5321 (SMTP)](https://www.rfc-editor.org/rfc/rfc5321.html) · [RFC 6409 (Message Submission for Mail)](https://www.rfc-editor.org/rfc/rfc6409.html) · [RFC 8314 (Cleartext considered obsolete — submission ports)](https://www.rfc-editor.org/rfc/rfc8314.html) · [CVE-2021-38371 (Exim STARTTLS injection)](https://nvd.nist.gov/vuln/detail/CVE-2021-38371) · [CVE-2021-33515 (Dovecot STARTTLS pre-handshake state leak)](https://nvd.nist.gov/vuln/detail/CVE-2021-33515)
+
 - v0.11.25 (2026-05-20) — **Five new primitives: sealed-token mail FTS + Stripe HMAC-SHA256 webhook verify + `b.money` + `b.fsm` + `b.auth.botChallenge`.** Five additive primitives in one release. Every consumer building on the framework — mail UIs, billing pipelines, e-commerce backends, multi-step business workflows, public web endpoints — now finds the substrate in-tree instead of reimplementing it. None of these replaces a default; every primitive is opt-in at the call site. Mail full-text search hashes tokens with the per-deployment vault salt before any byte hits the SQLite FTS5 index, so the index is searchable but a database dump leaks nothing readable. The Stripe-shaped HMAC-SHA-256 verifier sits next to the existing PQC and SHA3-512 webhook signers; the `whsec_` prefix stays in the key bytes per Stripe's spec; signatures are constant-time-compared and replay-defended via an operator-supplied nonce store. `b.money` arithmetic is BigInt-only across 40 ISO 4217 currencies with largest-remainder allocation and banker's-rounding FX conversion. `b.fsm` is the in-process sibling of `b.agent.saga` — declarative state + transition definition, guards, async on-enter/on-exit, drop-silent audit on every transition, with a transition-serialisation lock that makes concurrent `.transition()` calls deterministic. `b.auth.botChallenge` composes `b.httpClient` for siteverify against Cloudflare Turnstile (default), hCaptcha, and reCAPTCHA-v3 — the secret bytes never appear in any audit metadata. **Added:** *`b.mailStore.fts` — sealed-token full-text index + `b.mailStore.create().search(folder, filter)`* — Every `appendMessage` now inserts a row into a SQLite FTS5 virtual table whose subject / address / body columns hold space-separated 16-char hex hashes — vault-salted SHA3 over each NFC-normalised token. The salt is the same `b.vault.getDerivedHashSalt()` `b.cryptoField` uses for sealed-column derived hashes, so rotating the vault salt invalidates the FTS index in step with every other sealed-row hash. Query terms go through the same tokenize → hash transform on the search path and issue FTS5 MATCH against the hash-token rows — the index is fully searchable without ever materialising the plaintext on disk. `b.mail.agent.search({ folder, filter })` now accepts `text` / `subject` / `body` / `from` / `to` filter keys; the agent layer hands them to the store. `hardExpunge` deletes the FTS row inside the same transaction as the canonical message row so the two cannot drift. Limits: 8192 tokens / row / field, 2..64 codepoint length band, 8 MiB input cap per field. Exact-token only (no prefix wildcard, no stemmer) — the cost of sealed-at-rest. · *`b.webhook.verify({ alg: 'hmac-sha256-stripe', secret, header, body, toleranceMs?, nonceStore? })` + `b.webhook.sign(...)`* — Stripe-spec inbound webhook signature verifier (Paddle + Shopify use the same shape). Parses `Stripe-Signature: t=<unix>,v1=<hex>[,v1=<hex>...]`, validates the timestamp is within the tolerance window (default 5 min; refuses below 30s), HMAC-SHA-256s `<t>.<body>` with the `whsec_...` secret bytes verbatim (the prefix IS the key — `b.webhook.verify` never strips it), and walks the v1 entries with `b.crypto.timingSafeEqual` so a rotation grace window doesn't leak which entry matched. `b.webhook.sign` is the round-trip companion for outbound Stripe-shaped emission and round-trip tests. Optional `nonceStore: { has(k), set(k, ttlMs) }` records the accepted signature so a replay within the tolerance window refuses. The header value is hard-capped at 4096 bytes and per-`v1` hex at 256 chars (anti-DoS). · *`b.money` — decimal-safe money + 40-currency ISO 4217 catalog* — BigInt minor units throughout — Number is refused at construction. Currency exponents covering 0 (JPY/KRW), 2 (USD/EUR/GBP/…), 3 (KWD/BHD/JOD/OMR/TND), 4 (CLF) are pre-populated. Surface: `b.money.of(amount, code)` / `b.money.fromMinorUnits(bigint, code)` / `b.money.parse('12.50 USD')` / `b.money.zero(code)` plus instance methods `.add` / `.subtract` / `.multiply` / `.allocate(weights[])` / `.negate` / `.abs` / `.equals` / comparison family / `.toMinorUnits()` / `.toString()` / `.toJSON()` / `.format(locale?)`. `b.money.convert(money, toCurrency, fxRateProvider)` rounds half-to-even (banker's rounding) by default. Cross-currency arithmetic throws; `0.10 + 0.20 === 0.30` exactly. Allocation uses largest-remainder so $10 / 3 = [$3.34, $3.33, $3.33] with sum preserved. · *`b.fsm` — in-process state machine (sibling of `b.agent.saga`)* — `b.fsm.define({ name, initial, states, transitions })` returns a frozen machine factory. `Machine.create({ initialContext })` returns an instance with `.state` / `.context` / `.history` / `.allowed()` / `.can(name)` / `.transition(name, opts)` / `.toJSON()`. Transitions carry an optional guard (predicate; refusal throws `fsm/guard-refused`) and trigger per-state `onEnter` / `onExit` side-effects (sync or returned-Promise — `.transition` awaits). Every transition emits a `fsm.<machineName>.transition` audit event via `b.audit.safeEmit` (drop-silent on hot path), including the actor + metadata the caller passed in. A transition lock serialises concurrent `.transition()` calls — the test suite exercises five parallel transitions and verifies only the legal path runs. State + transition names are identifier-shape only (`safeSql.DEFAULT_IDENTIFIER_RE`) so a name never lands in SQL / HTML un-validated. `Machine.restore(snapshot)` rebuilds an instance from a prior `.toJSON()` snapshot — state + history + context survive a process restart. · *`b.auth.botChallenge.create({ secret, provider?, ... }) → { verify(token, opts?) }`* — Server-side challenge-response verifier for Cloudflare Turnstile (default), hCaptcha, and reCAPTCHA-v3. Composes `b.httpClient` for the outbound `/siteverify` POST — every request rides the framework's SSRF guard + DNS pinning + retry policy; the operator's secret never appears in a URL or any audit metadata field. Body encoding is `application/x-www-form-urlencoded` per the provider specs. Returns `{ ok, provider, hostname, action, challengeTs, score?, raw }` on success; throws `BotChallengeError` with structured codes (`invalid-token`, `timeout`, `hostname-mismatch`, `action-mismatch`, `provider-error`) on failure, with the upstream `error-codes` array exposed at `err.errorCodes`. Per-factory `allowedHostnames` + `allowedActions` allowlists; per-call `expectedHostname` + `expectedAction` overrides. Tokens are refused at the factory boundary if empty / non-string / > 4096 bytes, before any outbound call. **Security:** *Mail FTS index leaks zero plaintext (sealed-at-rest invariant extended)* — Pre-v0.11.25, the only operator-facing search path on `b.mail.agent` was a modseq cursor + post-fetch unseal — fast for cursoring but useless for text content discovery. Plaintext-FTS would have broken the sealed-at-rest invariant. The new index hashes every indexed token with the per-deployment vault salt before insert; a `sqlite3 .dump` produces ASCII-hex tokens indistinguishable from random. The same vault salt protects every `b.cryptoField`-sealed column, so adding the FTS index does NOT widen the cryptographic trust boundary. · *Stripe verifier defends the documented attack surface* — Constant-time HMAC compare (timing-safe across the v1 rotation list — operators don't leak which entry matched). Per-`v1` 256-hex anti-DoS cap. Tolerance-window minimum 30s — refuses operator misconfiguration that would accept hour-old signatures. The `whsec_` prefix preservation is encoded as a `codebase-patterns` detector (`stripe-hmac-sha256-no-strip-whsec-prefix`) so re-introducing the strip-bug is impossible without tripping a release gate. · *Bot-challenge secret never reaches audit / logs* — `b.auth.botChallenge` audit emits `{ provider, hostname, ok, errorCodes }` — the operator's secret bytes never appear in any metadata key. A `codebase-patterns` detector (`bot-challenge-secret-not-in-audit`) scans `lib/auth/bot-challenge.js` for any `audit.*emit` window that references `secret` so a future refactor cannot regress. **Detectors:** *Five new `codebase-patterns` detectors encode the shape-specific bug classes* — `stripe-hmac-sha256-no-strip-whsec-prefix` flags `secret.replace(/^whsec_/, '')` / `secret.slice(6)` near an HMAC call (the `whsec_` prefix IS the key). `no-number-money-arithmetic` flags `b.money.of(<Number>, ...)` and Number / Money arithmetic (precision lost; only BigInt / string OK at construction). `fsm-transition-without-await` flags `<fsm>.transition(...)` without `await` or `.then` in `lib/` (the transition is async; sync misuse swallows errors). `bot-challenge-secret-not-in-audit` is file-scoped to `lib/auth/bot-challenge.js` and flags any `audit.*emit` window or `metadata: { ... }` object literal referencing `secret`. Each detector is wired into `codebase-patterns.test.js`'s `run()` so every future commit re-checks the shape. **References:** [RFC 2104 (HMAC)](https://www.rfc-editor.org/rfc/rfc2104.html) · [RFC 6234 (US Secure Hash Algorithms — SHA-256)](https://www.rfc-editor.org/rfc/rfc6234.html) · [Stripe webhook signature spec](https://docs.stripe.com/webhooks/signature) · [Paddle webhook signature verification](https://developer.paddle.com/webhooks/signature-verification) · [Shopify webhooks — HMAC verification](https://shopify.dev/docs/apps/webhooks/configuration/https) · [ISO 4217 (Currency codes + minor unit catalog)](https://www.iso.org/iso-4217-currency-codes.html) · [IEEE 754 (the float-precision problem `b.money` avoids)](https://standards.ieee.org/standard/754-2019.html) · [Cloudflare Turnstile — server-side validation](https://developers.cloudflare.com/turnstile/get-started/server-side-validation/) · [hCaptcha — verify the user response server-side](https://docs.hcaptcha.com/) · [reCAPTCHA-v3 — server-side verification](https://developers.google.com/recaptcha/docs/v3) · [OWASP ASVS v5 §11.5 — bot defense controls](https://owasp.org/www-project-application-security-verification-standard/) · [RFC 9051 (IMAP4rev2 — SEARCH semantics)](https://www.rfc-editor.org/rfc/rfc9051.html) · [RFC 8621 (JMAP Mail — Email/query)](https://www.rfc-editor.org/rfc/rfc8621.html) · [SQLite FTS5](https://www.sqlite.org/fts5.html) · [UML State Machine (OMG UML 2.5.1 §14)](https://www.omg.org/spec/UML/2.5.1)
 
 - v0.11.24 (2026-05-20) — **`b.mail.send.deliver` — turnkey outbound SMTP composer (MX → MTA-STS → DANE → REQUIRETLS → DSN).** One factory wires together the full outbound mail chain. The operator hands the primitive an envelope (`{ from, to, rfc822 }`) and gets back per-recipient outcomes: `delivered`, `deferred` (with retry budget), or `failed` (with the corresponding RFC 3464 DSN already composed and the configured DSN sink invoked). Per-recipient handling is independent — one recipient permanently failing does not interfere with another's delivery or retry. MX records are resolved live (operator may inject a resolver for testing), MTA-STS policy (RFC 8461) is fetched + matched against the resolved MX before TLS, DANE TLSA records (RFC 7672) are consulted when present, REQUIRETLS (RFC 8689) is honored, and the per-host SMTP transport is the framework's `b.mail.smtpTransport`. SMTP outcomes are classified deterministically: hard 5xx + null-MX → permanent (with DSN); soft 4xx + DNS / connect / TLS errors → transient (with backoff budget). Recipient cap (1000 per call) and per-host / per-lookup timeout caps are baked in. **Added:** *`b.mail.send.deliver.create(opts) → async deliver(envelope)` — composed outbound delivery* — Factory returns a `deliver(envelope)` async function. `envelope = { from, to[], rfc822 }`. Returns `{ delivered: [{...}], deferred: [{...}], failed: [{...}] }`. Composes `b.network.smtp.policy.mtaSts.fetch` + `.matchMx`, `b.network.smtp.policy.dane.tlsa` + `.verifyChain`, `b.mail.smtpTransport.create`, and `b.audit.safeEmit`. Required opts: `hostname` (EHLO + MAIL FROM identity). Optional: `resolver` (object exposing `resolveMx` / `resolve` — defaults to node:dns/promises); `policy.mtaSts.enabled` (default true); `policy.dane.enabled` (default true); `retry.maxAttempts` (default 5); `retry.backoffMs` (default exponential 60s/5m/30m/2h/12h); `dsn.from` + `dsn.onPermanentFailure(messageBuffer, ctx)` (required only when DSN delivery is desired); `timeouts.mxLookupMs` (default 5s); `timeouts.perHostMs` (default 60s); `transportFactory` (test-injection override). · *Per-recipient outcome classifier (`_classifySmtpOutcome`)* — Maps SMTP reply codes + Node socket / TLS errors onto the `permanent` / `transient` axis. Permanent: SMTP 5xx (any subclass), null-MX RFC 7505 sentinel `.`, no-MX-records, RFC 5321 §3.6.2 unrouteable. Transient: SMTP 4xx (any subclass), TCP connection refused / reset / timeout, TLS handshake failure (when MTA-STS / DANE is not enforce-mode), DNS NXDOMAIN at lookup time. Once `retry.maxAttempts` is exhausted, transient is escalated to permanent with reason `retry exhausted (after N attempts)`. · *RFC 3464 DSN composer (`_buildDsnMessage`)* — Builds a `multipart/report; report-type=delivery-status` message with three parts: human-readable explanation, `message/delivery-status` block (Reporting-MTA, Original-Recipient, Final-Recipient, Action: failed, Status: 5.x.x), and a `message/rfc822-headers` block carrying the failed message's headers. Boundary token is generated via `b.crypto.generateToken(12)` so it can't collide with attacker-chosen header / body bytes. The composed DSN is passed to the operator-supplied `dsn.onPermanentFailure(message, ctx)` sink — the primitive does not itself send the DSN, keeping the operator in control of which transport carries DSNs (typically the same submission service). · *MX failover + per-host audit* — MX records are walked in priority order. A failed connect / TLS / 4xx on the first host falls over to the next; only when every MX has been tried does the recipient receive its final outcome. Each per-host failure emits a structured audit event (`mail.send.deliver.host-fail` with `recipient` + `mxHost` + `priority` + `reason`); the final outcome emits `mail.send.deliver.delivered` / `.deferred` / `.permanent-fail`. Audit is drop-silent on the hot path (catch + ignore). · *Recipient + envelope hard caps* — `MAX_RECIPIENTS_PER_CALL = 1000` refuses oversized fan-out at the factory boundary (5xx-style DoS prevention). `envelope.rfc822` accepts a Buffer or UTF-8 string — strings are converted at the boundary so downstream byte-level reasoning (DKIM, REQUIRETLS, length headers) sees stable bytes. Bad-envelope refusals carry `DeliverError` codes `deliver/bad-envelope`, `/bad-envelope-from`, `/bad-envelope-to`, `/too-many-recipients`, `/bad-envelope-rfc822` — operators get structured surface for each refusal class. **Security:** *MTA-STS enforcement before TLS handshake (RFC 8461)* — When `policy.mtaSts.enabled` (default), MTA-STS policy is fetched for the recipient domain. If the policy mode is `enforce` and a resolved MX hostname does not match an `mx:` entry, the host is refused without attempting TLS. This closes the MX-substitution attack window (`b.mail.send.deliver` cannot be diverted to an attacker-controlled MX even when DNS is hijacked, as long as the recipient publishes MTA-STS). · *DANE TLSA verification when present (RFC 7672)* — When `policy.dane.enabled` (default) and the recipient domain publishes TLSA records, the SMTP transport's TLS certificate chain is verified against the TLSA hash before the SMTP command pipeline starts. TLSA records take precedence over PKIX trust roots for SMTP — RFC 7672 §2.2. · *Boundary token unguessable (DSN boundary-injection defense)* — MIME boundary token in composed DSNs is 12 random bytes hex-encoded via `b.crypto.generateToken` (SHAKE256 over OS-RNG) — not `Date.now()` + `Math.random()`. The boundary appears verbatim in the message; a predictable boundary would let an attacker who controls the failed message's headers craft byte sequences that close the boundary early + inject MIME parts. **Detectors:** *`per-recipient-loop-fallthrough-to-failed` (codebase-patterns)* — A new detector flags per-recipient delivery loops where the `delivered` branch does not exit the iteration before falling into the permanent-failure / DSN-emit path. Encodes the bug class that was caught during this slice's bring-up — a recipient delivering successfully also being added to `failed[]` because the `if (delivered)` branch lacked an explicit `continue`. **References:** [RFC 5321 (Simple Mail Transfer Protocol)](https://www.rfc-editor.org/rfc/rfc5321.html) · [RFC 3464 (Extensible Message Format for Delivery Status Notifications)](https://www.rfc-editor.org/rfc/rfc3464.html) · [RFC 7505 (Null MX no-service resource record)](https://www.rfc-editor.org/rfc/rfc7505.html) · [RFC 8461 (SMTP MTA Strict Transport Security — MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html) · [RFC 7672 (SMTP Security via Opportunistic DANE TLS)](https://www.rfc-editor.org/rfc/rfc7672.html) · [RFC 8689 (SMTP REQUIRETLS option)](https://www.rfc-editor.org/rfc/rfc8689.html) · [RFC 3463 (Enhanced Mail System Status Codes)](https://www.rfc-editor.org/rfc/rfc3463.html)

package/lib/mail-server-mx.js

@@ -360,7 +360,11 @@ function create(opts) {
       lastDataByteTime: 0,
     };
 
-    var lineBuffer = "";
+    // Raw byte buffer (NOT a string) — DATA bodies under 8BITMIME may
+    // carry bytes that are invalid UTF-8; round-tripping through a
+    // string decode would replace them with U+FFFD and corrupt the
+    // message. Decode to string only for the per-command line parse.
+    var lineBuffer = Buffer.alloc(0);
     var bodyCollector = null;
     var inDataBody = false;
 
@@ -447,8 +451,8 @@ function create(opts) {
         return;
       }
 
-      // Command phase — line-buffered.
-      lineBuffer += chunk.toString("utf8");
+      // Command phase — byte-buffered (8BITMIME-safe).
+      lineBuffer = lineBuffer.length === 0 ? chunk : Buffer.concat([lineBuffer, chunk]);
       if (lineBuffer.length > maxLineBytes * 4) {
         _writeReply(socket, REPLY_500_SYNTAX,
           "5.5.6 Line too long (>" + maxLineBytes + " bytes)");
@@ -456,9 +460,10 @@ function create(opts) {
         return;
       }
       var crlf;
-      while ((crlf = lineBuffer.indexOf("\r\n")) !== -1) {
-        var line = lineBuffer.slice(0, crlf);
-        lineBuffer = lineBuffer.slice(crlf + 2);
+      var crlfNeedle = Buffer.from("\r\n", "ascii");
+      while ((crlf = lineBuffer.indexOf(crlfNeedle)) !== -1) {
+        var line = lineBuffer.subarray(0, crlf).toString("utf8");
+        lineBuffer = lineBuffer.subarray(crlf + 2);
         _handleCommand(state, socket, line);
         if (inDataBody) return;
       }
@@ -584,7 +589,7 @@ function create(opts) {
       // (RFC 2920) pre-handshake cannot reach the post-TLS state
       // machine. Listener-removal + idle-timeout re-arm live in the
       // shared upgradeSocket helper (b.mail.server.tls.upgradeSocket).
-      lineBuffer    = "";
+      lineBuffer    = Buffer.alloc(0);
       bodyCollector = null;
       inDataBody    = false;
       mailServerTls.upgradeSocket({

package/lib/mail-server-submission.js

@@ -428,9 +428,27 @@ function create(opts) {
       authPending:   null,
     };
 
-    var lineBuffer = "";
+    // RAW byte buffer — NOT a string. The BDAT-CHUNKING path (RFC 3030)
+    // requires lossless byte preservation when the BDAT command line +
+    // payload arrive in the same TCP segment, and DATA-body 8BITMIME
+    // payloads can contain bytes that are invalid UTF-8. Decoding the
+    // socket-bytes through a string layer replaces invalid sequences
+    // with U+FFFD and corrupts the body. Keep the raw bytes; decode to
+    // string only for the per-command parse.
+    var lineBuffer = Buffer.alloc(0);
     var bodyCollector = null;
     var inDataBody = false;
+    // RFC 3030 CHUNKING — state for the BDAT command. `bdatCollector`
+    // accumulates the message body across multiple BDAT chunks; it lives
+    // for the lifetime of the SMTP transaction (i.e., between MAIL FROM
+    // and the BDAT ... LAST that finalises). `bdatRemaining` counts down
+    // bytes still owed by the current BDAT chunk; `bdatIsLast` flags
+    // whether the current chunk is the terminator.
+    var inBdatChunk    = false;
+    var bdatRemaining  = 0;
+    var bdatIsLast     = false;
+    var bdatCollector  = null;
+    var bdatTotalBytes = 0;
 
     socket.setTimeout(idleTimeoutMs);
     socket.on("timeout", function () {
@@ -465,6 +483,57 @@ function create(opts) {
     });
 
     function _ingestBytes(state, socket, chunk) {
+      // RFC 3030 — when a BDAT chunk is in progress we consume exactly
+      // `bdatRemaining` bytes off the wire, no dot-stuffing, no end-of-
+      // data marker. Any excess bytes in the chunk after the BDAT
+      // payload completes get fed back through the command line buffer
+      // (typical when a pipelined `BDAT N LAST\r\n<payload>\r\nNOOP\r\n`
+      // arrives in a single TCP segment).
+      if (inBdatChunk) {
+        var consumeN = Math.min(chunk.length, bdatRemaining);
+        var consumed = chunk.subarray(0, consumeN);
+        try { bdatCollector.push(consumed); }
+        catch (_e) {
+          _emit("mail.server.submission.bdat_refused",
+            { connectionId: state.id, reason: "body-too-large", maxBytes: maxMessageBytes },
+            "denied");
+          _writeReply(socket, REPLY_552_SIZE_EXCEEDED,
+            "5.3.4 BDAT body exceeds maxMessageBytes (" + maxMessageBytes + " bytes)");
+          _resetTransaction(state);
+          inBdatChunk = false; bdatCollector = null; bdatRemaining = 0; bdatTotalBytes = 0;
+          return;
+        }
+        bdatRemaining -= consumeN;
+        bdatTotalBytes += consumeN;
+        if (bdatRemaining === 0) {
+          var wasLast = bdatIsLast;
+          inBdatChunk = false;
+          if (wasLast) {
+            // RFC 3030 §2.2 — ONE reply per BDAT command. When LAST,
+            // the single reply is the "message queued" finalize reply
+            // (emitted from _finalizeAcceptedBody), not the per-chunk
+            // "<N> octets received" reply. Emitting both would
+            // desynchronise the client (the second 250 would be
+            // consumed as the response to the next command).
+            // No dot-unstuff for BDAT — RFC 3030 §3 explicitly defines
+            // BDAT payloads as opaque byte streams.
+            var bdatBody = bdatCollector.result();
+            bdatCollector = null;
+            bdatTotalBytes = 0;
+            _finalizeAcceptedBody(state, socket, bdatBody, "BDAT");
+          } else {
+            // Non-final chunk — per-chunk acknowledgement only.
+            _writeReply(socket, REPLY_250_OK,
+              "2.0.0 " + bdatTotalBytes + " octets received");
+          }
+          // Any tail bytes after this BDAT chunk get re-fed as commands.
+          if (consumeN < chunk.length) {
+            var tail = chunk.subarray(consumeN);
+            _ingestBytes(state, socket, tail);
+          }
+        }
+        return;
+      }
       if (inDataBody) {
         try { bodyCollector.push(chunk); }
         catch (_e) {
@@ -491,13 +560,15 @@ function create(opts) {
         var endIdx = safeSmtp.findDotTerminator(collected);
         if (endIdx !== -1) {
           var body = collected.subarray(0, endIdx);
-          _finalizeDataBody(state, socket, body);
+          // DATA path dot-unstuffs here; BDAT path skips this step.
+          var dedotted = safeSmtp.dotUnstuff(body);
+          _finalizeAcceptedBody(state, socket, dedotted, "DATA");
           inDataBody = false; bodyCollector = null;
         }
         return;
       }
 
-      lineBuffer += chunk.toString("utf8");
+      lineBuffer = lineBuffer.length === 0 ? chunk : Buffer.concat([lineBuffer, chunk]);
       if (lineBuffer.length > maxLineBytes * 4) {
         _writeReply(socket, REPLY_500_SYNTAX,
           "5.5.6 Line too long (>" + maxLineBytes + " bytes)");
@@ -505,11 +576,29 @@ function create(opts) {
         return;
       }
       var crlf;
-      while ((crlf = lineBuffer.indexOf("\r\n")) !== -1) {
-        var line = lineBuffer.slice(0, crlf);
-        lineBuffer = lineBuffer.slice(crlf + 2);
+      var crlfNeedle = Buffer.from("\r\n", "ascii");
+      while ((crlf = lineBuffer.indexOf(crlfNeedle)) !== -1) {
+        // Decode just the per-command line to a string — keeps the
+        // wire-protocol parser working in UTF-8 while leaving the
+        // RAW lineBuffer intact for any binary payload that follows.
+        var line = lineBuffer.subarray(0, crlf).toString("utf8");
+        lineBuffer = lineBuffer.subarray(crlf + 2);
         _handleCommand(state, socket, line);
         if (inDataBody) return;
+        if (inBdatChunk) {
+          // RFC 3030 — `BDAT <N> [LAST]\r\n` is immediately followed by
+          // exactly <N> raw bytes (no dot-stuffing, no terminator). When
+          // those bytes arrived in the SAME TCP segment as the BDAT
+          // command, drain them straight from the raw byte buffer
+          // (NOT through a UTF-8 string round-trip — would corrupt
+          // 8-bit / binary payloads).
+          if (lineBuffer.length > 0) {
+            var pendingBytes = lineBuffer;
+            lineBuffer = Buffer.alloc(0);
+            _ingestBytes(state, socket, pendingBytes);
+          }
+          return;
+        }
       }
     }
 
@@ -555,6 +644,8 @@ function create(opts) {
           return _handleRcptTo(state, socket, line);
         case "DATA":
           return _handleData(state, socket);
+        case "BDAT":
+          return _handleBdat(state, socket, line);
         case "NOOP":
           return _writeReply(socket, REPLY_250_OK, "2.0.0 OK");
         case "RSET":
@@ -592,7 +683,7 @@ function create(opts) {
       state.helo  = helo;
       state.stage = "ehlo";
       if (verb === "EHLO") {
-        var caps = ["PIPELINING", "SIZE " + maxMessageBytes, "8BITMIME", "ENHANCEDSTATUSCODES"];
+        var caps = ["PIPELINING", "SIZE " + maxMessageBytes, "8BITMIME", "ENHANCEDSTATUSCODES", "CHUNKING"];
         // STARTTLS advertised only on explicit-STARTTLS port (587),
         // not on implicit-TLS (465 already wrapped). RFC 8314 §3.3.
         if (!state.tls && !implicitTls) caps.unshift("STARTTLS");
@@ -627,7 +718,12 @@ function create(opts) {
       // body collector AND strip the plain-socket "data" listener
       // before wrapping in TLSSocket so bytes the peer pipelined
       // pre-handshake cannot reach the post-TLS state machine.
-      lineBuffer = ""; bodyCollector = null; inDataBody = false;
+      lineBuffer = Buffer.alloc(0); bodyCollector = null; inDataBody = false;
+      // BDAT-side state cleared on STARTTLS upgrade too — same threat
+      // model as CVE-2021-38371 (Exim) / CVE-2021-33515 (Dovecot):
+      // pre-handshake bytes the peer pipelined MUST NOT reach the
+      // post-TLS state machine via the BDAT collector either.
+      inBdatChunk = false; bdatRemaining = 0; bdatCollector = null; bdatTotalBytes = 0;
       mailServerTls.upgradeSocket({
         plainSocket:   socket,
         secureContext: opts.tlsContext,
@@ -1033,8 +1129,7 @@ function create(opts) {
       });
     }
 
-    function _finalizeDataBody(state, socket, body) {
-      var dedotted = safeSmtp.dotUnstuff(body);
+    function _finalizeAcceptedBody(state, socket, dedotted, source) {
 
       // Outbound DKIM-required gate. Scan the header block for a
       // `DKIM-Signature:` line; under `self` mode also require at
@@ -1108,16 +1203,109 @@ function create(opts) {
       }
       _emit("mail.server.submission.data_accepted",
         { connectionId: state.id, mailFrom: state.mailFrom,
-          rcptCount: state.rcpts.length, sizeBytes: dedotted.length });
+          rcptCount: state.rcpts.length, sizeBytes: dedotted.length, source: source || "DATA" });
       _writeReply(socket, REPLY_250_OK, "2.6.0 Message queued (audit-only)");
       _resetTransaction(state);
     }
 
+    // RFC 3030 §2 — BDAT <chunk-size> [LAST]. Reads exactly chunk-size
+    // bytes off the wire (no dot-stuffing, no end-of-data marker). The
+    // size is a non-negative integer; LAST keyword (case-insensitive)
+    // terminates the message body. Mixing DATA + BDAT within the same
+    // transaction is forbidden — the server returns 503 once the first
+    // BDAT lands and forces the client to RSET.
+    function _handleBdat(state, socket, line) {
+      if (state.stage !== "rcpt" && state.stage !== "bdat") {
+        _writeReply(socket, REPLY_503_BAD_SEQUENCE, "5.5.1 BDAT requires MAIL FROM + RCPT TO");
+        return;
+      }
+      if (state.rcpts.length === 0) {
+        _writeReply(socket, REPLY_503_BAD_SEQUENCE, "5.5.1 No valid recipients");
+        return;
+      }
+      // Pipelining race — same gate as DATA.
+      if ((state.rcptsPending || 0) > 0) {
+        _emit("mail.server.submission.pipelining_bdat_race", {
+          connectionId: state.id, rcptsPending: state.rcptsPending,
+          rcptsCommitted: state.rcpts.length,
+        }, "denied");
+        _writeReply(socket, REPLY_451_LOCAL_ERROR,
+          "4.5.0 RCPT TO verdicts pending; reissue BDAT after recipient replies");
+        return;
+      }
+      // Parse `BDAT <size>[ LAST]`.
+      var parts = line.split(/\s+/);
+      if (parts.length < 2 || parts.length > 3) {
+        _writeReply(socket, REPLY_501_BAD_ARGS, "5.5.4 BDAT requires <chunk-size> [LAST]");
+        return;
+      }
+      var sizeStr = parts[1];
+      var sizeN = parseInt(sizeStr, 10);
+      if (!/^\d+$/.test(sizeStr) || !isFinite(sizeN) || sizeN < 0) {
+        _writeReply(socket, REPLY_501_BAD_ARGS, "5.5.4 BDAT chunk-size must be a non-negative integer");
+        return;
+      }
+      var isLast = parts.length === 3 && parts[2].toUpperCase() === "LAST";
+      if (parts.length === 3 && !isLast) {
+        _writeReply(socket, REPLY_501_BAD_ARGS, "5.5.4 BDAT third arg must be 'LAST' (RFC 3030 §2)");
+        return;
+      }
+      // Cumulative-size cap. The collector is bounded too, but checking
+      // up-front lets us refuse the chunk before reading bytes off the
+      // socket — important when sizeN >> maxMessageBytes.
+      if (bdatTotalBytes + sizeN > maxMessageBytes) {
+        _emit("mail.server.submission.bdat_refused",
+          { connectionId: state.id, reason: "body-too-large",
+            requestedTotal: bdatTotalBytes + sizeN, maxBytes: maxMessageBytes }, "denied");
+        _writeReply(socket, REPLY_552_SIZE_EXCEEDED,
+          "5.3.4 BDAT cumulative size " + (bdatTotalBytes + sizeN) +
+          " exceeds maxMessageBytes (" + maxMessageBytes + ")");
+        _resetTransaction(state);
+        bdatCollector = null; bdatTotalBytes = 0;
+        return;
+      }
+      if (!bdatCollector) {
+        bdatCollector = safeBuffer.boundedChunkCollector({
+          maxBytes:    maxMessageBytes,
+          errorClass:  MailServerSubmissionError,
+          sizeCode:    "mail-server-submission/body-too-large",
+          sizeMessage: "BDAT body exceeded maxMessageBytes (" + maxMessageBytes + ")",
+        });
+      }
+      state.stage   = "bdat";
+      bdatRemaining = sizeN;
+      bdatIsLast    = isLast;
+      // size=0 + LAST is a valid sequence — finalises the message
+      // body (the LAST chunk may carry zero bytes when the prior chunk
+      // was the final payload). RFC 3030 §2.2 — ONE reply per command:
+      // emit the "0 octets" ack for size=0 NOT-LAST, but defer to
+      // _finalizeAcceptedBody for size=0 LAST.
+      if (sizeN === 0) {
+        if (isLast) {
+          var emptyBody = bdatCollector ? bdatCollector.result() : Buffer.alloc(0);
+          bdatCollector = null; bdatTotalBytes = 0;
+          _finalizeAcceptedBody(state, socket, emptyBody, "BDAT");
+        } else {
+          _writeReply(socket, REPLY_250_OK, "2.0.0 0 octets received");
+        }
+        return;
+      }
+      inBdatChunk = true;
+    }
+
     function _resetTransaction(state) {
       state.mailFrom     = null;
       state.rcpts        = [];
       state.rcptsPending = 0;
       state.stage        = "ehlo";
+      // BDAT-side state lives at the connection level, not on `state`.
+      // Reset it here so a RSET / failed BDAT can't leak collected
+      // bytes into the next transaction.
+      inBdatChunk    = false;
+      bdatRemaining  = 0;
+      bdatIsLast     = false;
+      bdatCollector  = null;
+      bdatTotalBytes = 0;
     }
   }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.11.25",
+  "version": "0.11.26",
   "description": "The Node framework that owns its stack.",
   "license": "Apache-2.0",
   "author": "blamejs contributors",

package/sbom.cdx.json

@@ -2,10 +2,10 @@
   "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
   "bomFormat": "CycloneDX",
   "specVersion": "1.5",
-  "serialNumber": "urn:uuid:6b814cb5-e99f-4bcb-a349-6b597ea780a6",
+  "serialNumber": "urn:uuid:3dcc0cb1-fcfe-4b62-b09b-3c1ab41e0b08",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-05-21T05:38:05.971Z",
+    "timestamp": "2026-05-21T06:48:21.305Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.11.25",
+      "bom-ref": "@blamejs/core@0.11.26",
       "type": "application",
       "name": "blamejs",
-      "version": "0.11.25",
+      "version": "0.11.26",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.11.25",
+      "purl": "pkg:npm/%40blamejs/core@0.11.26",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.11.25",
+      "ref": "@blamejs/core@0.11.26",
       "dependsOn": []
     }
   ]