@rapidmx/activesync-plugin 1.0.0-beta.2 → 1.0.0-beta.3

package/dist/types/adapters/EmailSyncAdapter.d.ts

@@ -13,7 +13,12 @@ import { type Mailbox, type Message } from "@rapidmx/restapi";
  * the only `Email` write EAS itself allows) - a plain-text-only pragmatic subset: no HTML body, no attachments
  * (mirrors `ComposeMailCommand`'s own already-documented attachment gap). `To`/`Cc`/`Bcc` (the latter MS-ASEMAIL2's
  * own `Bcc` tag) are ghosted independently per recipient type, not as one combined group - a `Change` touching
- * only one of them leaves the others untouched, carried over from `existing.recipients`.
+ * only one of them leaves the others untouched, carried over from `existing.recipients`. A new Draft always gets a body
+ * blob (empty when no `Body` was sent), so `ItemOperations` can fetch it like any other message.
+ *
+ * `Flag` is the MS-ASEMAIL container form in both directions: `<Flag><Status>2</Status></Flag>` (tokenized as
+ * `FlagStatus`) for a flagged message, an empty `<Flag/>` otherwise; `Status` 0/1 (cleared/complete) or an empty
+ * `Flag` from the device clears `flags.flagged`.
  *
  * Emits MS-ASEMAIL2's `Email2:ConversationId` (read-only - no `fromApplicationData` handling, since EAS itself
  * never lets a client set it) whenever `Message.conversationId` is populated, so a device's threaded-view UI can
@@ -27,23 +32,31 @@ import { type Mailbox, type Message } from "@rapidmx/restapi";
  * already takes for a stale search-index entry. Deliberately not writable: unlike `Contact.categories` (a
  * plain free-form string array with no separate entity behind it), a `Label` is a real mailbox-scoped entity
  * referenced by uid - a write path would need to resolve category name strings back to `Label`s and create new
- * ones on the fly for names that don't exist yet, real added scope this pragmatic subset defers. One `find()`
- * per message that actually has labels (most won't, since labels are opt-in) - not batched across a whole Sync
- * page/search result set, a documented, modest N+1 tradeoff rather than widening this adapter's own interface
- * further to let a caller pre-resolve names for a whole batch.
+ * ones on the fly for names that don't exist yet, real added scope this pragmatic subset defers. Callers
+ * rendering a whole Sync page/search result set use `toApplicationDataBatch()`, which resolves every referenced
+ * label with one `in(...)` query per mailbox rather than one per labelled message.
  *
- * `labelClass` is supplied by the Mongo/SQL concrete subclasses.
+ * `labelClass`/`folderClass` are supplied by the Mongo/SQL concrete subclasses.
  *
  * @author Jean-Philippe Steinmetz
  */
 export declare abstract class EmailSyncAdapter implements EasCollectionSyncAdapter<Message> {
     readonly collectionClass = "Email";
     protected abstract labelClass: any;
+    protected abstract folderClass: any;
     private _objectFactory?;
     private labelRepo?;
+    private folderRepo?;
     private blobStore?;
     init(): Promise<void>;
     toApplicationData(message: Message): Promise<WbxmlElement>;
+    /** Renders a whole page of messages, resolving every referenced `Label` with one `find()` per distinct
+     * mailbox (in practice one per page) instead of one per labelled message. */
+    toApplicationDataBatch(messages: Message[]): Promise<WbxmlElement[]>;
+    private render;
+    /** Resolves every distinct `labelUids` entry across `messages` to its `Label.name`, keyed by `labelKey()`.
+     * Labels are mailbox-scoped, so uids are grouped per `mailboxUid` and each group is fetched with a single
+     * `in(...)` query (chunked to stay within `RepoUtils`' page size). A stale uid simply has no entry. */
     private resolveLabelNames;
     /**
      * `Message.bodyBlobKey` is documented (see the `Message` interface itself) as holding raw MIME "unmodified
@@ -53,7 +66,11 @@ export declare abstract class EmailSyncAdapter implements EasCollectionSyncAdapt
      * for every consumer, not just this write path - a Draft created/edited via `Sync` must `Fetch` correctly
      * the same way any other message does.
      */
-    fromApplicationData(el: WbxmlElement, existing?: Message): Promise<Partial<Message>>;
+    fromApplicationData(el: WbxmlElement, existing?: Message, mailbox?: Mailbox): Promise<Partial<Message>>;
+    /** Whether `message` is a genuine draft (`MessageMoveRules.isGenuineDraft`): in its mailbox's Drafts folder, and
+     * never delivered. Moving any other message into Drafts is refused over ActiveSync, so its body can't be rewritten
+     * here by first moving it there. */
+    private isDraft;
     /** Defaults for a brand-new Draft created via a client-originated `Add` - `from` is the caller's own
      * mailbox address, per `ComposeMailCommand`'s identical `{ address, type: RecipientType.TO }` shape
      * convention for a `from` field (the `Recipient` struct's `type` is only meaningful for real recipients;

package/dist/types/adapters/mongo/EmailSyncAdapterMongo.d.ts

@@ -4,4 +4,5 @@ import { EmailSyncAdapter } from "../EmailSyncAdapter.js";
  */
 export declare class EmailSyncAdapterMongo extends EmailSyncAdapter {
     protected labelClass: any;
+    protected folderClass: any;
 }

package/dist/types/adapters/sql/EmailSyncAdapterSQL.d.ts

@@ -4,4 +4,5 @@ import { EmailSyncAdapter } from "../EmailSyncAdapter.js";
  */
 export declare class EmailSyncAdapterSQL extends EmailSyncAdapter {
     protected labelClass: any;
+    protected folderClass: any;
 }

package/dist/types/codec/WbxmlDecoder.d.ts

@@ -1,9 +1,41 @@
 import type { WbxmlElement } from "./WbxmlElement.js";
+/** Default cap on the total number of elements decoded from one document. An element costs as little as one
+ * wire byte (an empty tag token), so without this a small body could allocate millions of element objects. */
+export declare const WBXML_DEFAULT_MAX_ELEMENTS = 50000;
+/** Default cap on the number of direct children of any single element. */
+export declare const WBXML_DEFAULT_MAX_CHILDREN_PER_ELEMENT = 10000;
+/** Default cap on element nesting depth (the root is depth 1). Nesting costs ~2 wire bytes per level and drives
+ * the decoder's recursion, so it needs its own bound; real EAS documents stay well under 20 levels. */
+export declare const WBXML_DEFAULT_MAX_DEPTH = 64;
+/** Limits applied by `WbxmlDecoder`. Every value must be a positive integer; omitted values use the defaults. */
+export interface WbxmlDecoderOptions {
+    /** Maximum total elements in the document. Default `WBXML_DEFAULT_MAX_ELEMENTS`. */
+    maxElements?: number;
+    /** Maximum direct children of any one element. Default `WBXML_DEFAULT_MAX_CHILDREN_PER_ELEMENT`. */
+    maxChildrenPerElement?: number;
+    /** Maximum nesting depth (root = 1). Default `WBXML_DEFAULT_MAX_DEPTH`. */
+    maxDepth?: number;
+}
+/** Thrown by `WbxmlDecoder.decode()` for malformed or unsupported input (truncated buffer, unterminated string,
+ * attribute-flagged tag, a length field running past the end of the buffer, ...). */
+export declare class WbxmlDecodeError extends Error {
+    constructor(message: string);
+}
+/** Thrown by `WbxmlDecoder.decode()` when a document exceeds a configured resource limit (element count,
+ * children per element, or nesting depth). A subclass of `WbxmlDecodeError`, so callers that treat every
+ * decoder failure as a bad request can catch just the base class. */
+export declare class WbxmlLimitError extends WbxmlDecodeError {
+    constructor(message: string);
+}
 /**
  * Decodes a WBXML byte stream (an EAS request/response body) back into a `WbxmlElement` tree — the exact
  * inverse of `WbxmlEncoder`. Reads the fixed EAS document header, skips its (always-empty, in real
  * ActiveSync traffic) string table, then parses the single root element.
  *
+ * Input is untrusted, so decoding is bounded: total elements, children per element and nesting depth are
+ * capped (see `WbxmlDecoderOptions`), throwing `WbxmlLimitError` when exceeded; all other malformed input throws
+ * `WbxmlDecodeError`. Text and opaque payloads are bounded by the input buffer itself.
+ *
  * The `publicid` header field is read via the same generic `mb_u_int32` reader used everywhere else, which is
  * only a partial implementation of the full WBXML spec for that field (a raw leading `0x00` byte would
  * signal "public identifier is a string-table reference" under the full spec, a form real ActiveSync traffic
@@ -13,12 +45,19 @@ import type { WbxmlElement } from "./WbxmlElement.js";
  * @author Jean-Philippe Steinmetz
  */
 export declare class WbxmlDecoder {
+    private readonly maxElements;
+    private readonly maxChildrenPerElement;
+    private readonly maxDepth;
     private buf;
     private pos;
     private currentPage;
     private depth;
+    private elementCount;
+    constructor(options?: WbxmlDecoderOptions);
     decode(data: Buffer): WbxmlElement;
     private readByte;
+    /** Throws unless at least `length` bytes remain from the current position. */
+    private requireAvailable;
     /** Decodes a WBXML `mb_u_int32`: base-128 digits, most significant group first, every byte but the last
      * carrying the 0x80 continuation bit. Mirrors `WbxmlEncoder.writeMbUint()`. */
     private readMbUint;

package/dist/types/codec/WbxmlEncoder.d.ts

@@ -1,17 +1,52 @@
 import type { WbxmlElement } from "./WbxmlElement.js";
+/** Token bytes are buffered in a small scratch array and flushed into a `Buffer` chunk once it reaches this
+ * many bytes (or before a text/opaque payload is appended as its own chunk). */
+export declare const WBXML_ENCODER_SCRATCH_SIZE = 4096;
+/** Options for `WbxmlEncoder`. */
+export interface WbxmlEncoderOptions {
+    /** Maximum size in bytes of an encoded document (header included). Must be a positive integer or
+     * `Infinity`; default `Infinity` (no limit). Exceeding it throws `WbxmlSizeLimitError`. */
+    maxBytes?: number;
+}
+/** Thrown by `WbxmlEncoder.encode()` when the encoded document would exceed the configured `maxBytes`. */
+export declare class WbxmlSizeLimitError extends Error {
+    readonly maxBytes: number;
+    constructor(maxBytes: number);
+}
+/** Returns the exact wire size of an `OPAQUE` token carrying `payloadLength` bytes (token + length + payload),
+ * so callers can check a large payload against a size budget before building the element. */
+export declare function wbxmlOpaqueSize(payloadLength: number): number;
 /**
  * Encodes a `WbxmlElement` tree into a WBXML byte stream, per MS-ASWBXML's encoding algorithm. Emits the
  * fixed EAS document header (`version=1.3, publicid=unknown, charset=UTF-8, empty string table`) followed by
  * the token stream for the given root element, switching code pages only when the page actually changes from
  * whatever was last active (starting from `AirSync`, page 0, the implicit default per spec).
  *
+ * Output is accumulated as a list of `Buffer` chunks (token bytes batched in a small scratch array, text/opaque
+ * payloads appended whole) and joined once at the end, so large payloads are never copied byte-by-byte. An
+ * optional `maxBytes` bounds the output size, throwing `WbxmlSizeLimitError` as soon as it would be exceeded.
+ *
  * @author Jean-Philippe Steinmetz
  */
 export declare class WbxmlEncoder {
-    private bytes;
+    private readonly maxBytes;
+    private chunks;
+    private scratch;
+    private size;
     private currentPage;
+    constructor(options?: WbxmlEncoderOptions);
     encode(root: WbxmlElement): Buffer;
+    /** Accounts for `length` more output bytes, throwing before anything is appended if that would exceed
+     * `maxBytes`. */
+    private reserve;
+    private writeByte;
+    /** Appends a payload as its own chunk, after flushing any pending token bytes to preserve ordering. */
+    private writeBuffer;
+    private flush;
     private writeElement;
+    /** A NUL byte terminates a WBXML inline string, so any U+0000 in `text` (e.g. a label name or subject
+     * controlled by another user) would end the string early and let the remaining bytes be parsed as tokens.
+     * UTF-8 never produces a 0x00 byte for any other code point, so stripping U+0000 is sufficient. */
     private writeStrI;
     private writeOpaque;
     /** Encodes `value` as a WBXML multi-byte unsigned integer (`mb_u_int32`): base-128 digits, most

package/dist/types/commands/ComposeMailCommand.d.ts

@@ -1,6 +1,11 @@
+import { RepoUtils } from "@rapidrest/service-core";
 import { type Message, RecoverableRepoUtils } from "@rapidmx/restapi";
 import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import { stripHeader } from "../MimeHeaderUtils.js";
 import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/** Most envelope recipients (To + Cc + Bcc) one composed message may carry. */
+export declare const MAX_COMPOSE_RECIPIENTS = 500;
+export { stripHeader };
 /**
  * Shared implementation for EAS `SendMail`, `SmartForward`, and `SmartReply` (MS-ASCMD `ComposeMail` namespace)
  * — all three submit a client-composed raw MIME body directly (`<Mime>`, opaque WBXML content) rather than
@@ -8,23 +13,33 @@ import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.
  * `BaseMessageRoute.send()`, which this class's `scanAndRelay()` call shares its scan-then-relay core with via
  * `MailSendUtils.ts`).
  *
+ * **Sender and envelope checks** (the MIME is entirely device-controlled): the raw bytes pass restapi's own originator
+ * rules before anything parses them (`MimeHeaderUtils.checkComposedOriginators`: an inline copy of restapi's
+ * `checkOriginatorHeaders` with `rejectAddressLikeDisplayNames`): exactly one `From`, at most one `Sender` (found by a tolerant lexer - `From :`, folded lines and bare-CR
+ * line breaks included), every address in them - group members too - the caller's own mailbox's primary or alias
+ * address, no address-like text outside an address (`<me@x> <victim@y>`), and no address in a display name or comment
+ * (`"ceo@y" <me@x>`, `me@x (victim@y)`), and - stricter than restapi - no empty group (`victims:;, me@x`). Anything
+ * else is HTTP 403 (a MIME with no `From` at all is HTTP 400), so a device can't send as, or appear to be, anyone else;
+ * the envelope sender is the validated `From`. A message with no To/Cc/Bcc address is answered with the command's own
+ * `Status` 119 (MessageHasNoRecipient), nothing relayed. The envelope is capped at `MAX_COMPOSE_RECIPIENTS`
+ * recipients (HTTP 400). `Bcc` recipients are delivered via the envelope, but every `Bcc` header field (found by the
+ * same lexer, so `Bcc :` too) is stripped from the relayed copy so other recipients never see it (the Sent Items copy
+ * keeps it). The Sent Items copy records the relay's own `Message-ID`/`conversationId` (bounded like restapi's), so
+ * recall and threading match what recipients received.
+ *
  * **Pragmatic subset, deliberately not the full MS-ASCMD semantics**:
  * - `SmartForward`/`SmartReply`'s `<Source>` (the message being forwarded/replied to) is used only to thread
  * the outgoing message (`inReplyTo`/`references`) and to flip the original's `Answered`/`Forwarded` flag - the
- * real spec has the *server* splice the original message's full content into the outgoing MIME so the client
- * never has to download-then-reupload it; this pragmatic subset instead expects the client's own `<Mime>` to
- * already be the complete outgoing message (which is what every mainstream client's own compose UI naturally
- * produces once it has fetched the original for display), matching this library's "pragmatic subset, not full
- * fidelity" precedent elsewhere (e.g. `FolderSyncCommand`'s SyncKey replay-protection gap).
+ * real spec has the *server* splice the original message's full content into the outgoing MIME; this subset
+ * expects the client's own `<Mime>` to already be the complete outgoing message. The flag flip needs `UPDATE` on
+ * the original's folder and is best-effort: the message has already been sent, so a denied or conflicting flag
+ * update is logged, never turned into a failed request.
  * - `ReplaceMime`/`AccountId`/`InstanceId` are not read - single-account, non-recurring-meeting compose only.
- * - Attachments present in the composed MIME are relayed correctly (`scanAndRelay()`'s `ScanPipeline` handles
- * the full raw message) but are not additionally persisted as `Attachment` records on the saved Sent Items
- * copy - `Message.hasAttachments` is still set correctly from the parsed MIME, just not each attachment's own
- * row (deferred, matching `ItemOperationsCommand`'s own future `Fetch`-of-Sent-Items scope).
+ * - Attachments present in the composed MIME are relayed correctly but are not additionally persisted as
+ * `Attachment` records on the saved Sent Items copy (`Message.hasAttachments` is still set).
  *
- * `folderClass`/`messageClass` are supplied by the Mongo/SQL concrete subclasses, and `markOriginal()` by the
- * `SmartForwardCommand`/`SmartReplyCommand` subclasses (a no-op here, since plain `SendMailCommand` never has a
- * `<Source>` to act on).
+ * `folderClass`/`messageClass`/`mailboxClass` are supplied by the Mongo/SQL concrete subclasses, and
+ * `markOriginal()` by the `SmartForwardCommand`/`SmartReplyCommand` subclasses.
  *
  * @author Jean-Philippe Steinmetz
  */
@@ -32,17 +47,20 @@ export declare abstract class ComposeMailCommand implements EasCommandHandler {
     abstract readonly command: string;
     protected abstract folderClass: any;
     protected abstract messageClass: any;
+    protected abstract mailboxClass: any;
     private _objectFactory?;
     protected folderRepo?: RecoverableRepoUtils<any>;
     protected messageRepo?: RecoverableRepoUtils<any>;
+    protected mailboxRepo?: RepoUtils<any>;
     private blobStore?;
     private mailTransport?;
     private scanPipeline?;
     private aclUtils?;
+    private logger;
     init(): Promise<void>;
-    /** Called once the outgoing message has been sent, only when the request carried a `<Source>` (i.e. this
-     * is a `SmartForward`/`SmartReply`, never a plain `SendMail`) - flips the referenced original message's own
-     * `Answered`/`Forwarded` flag. A no-op here; overridden by the two subclasses that need it. */
+    /** Called once the outgoing message has been sent, only when the request carried a `<Source>` the caller may
+     * update - flips the referenced original message's own `Answered`/`Forwarded` flag. A no-op here; overridden by
+     * the two subclasses that need it. */
     protected markOriginal(_ctx: EasCommandContext, _original: Message & {
         uid: string;
     }): Promise<void>;

package/dist/types/commands/FolderSyncCommand.d.ts

@@ -7,6 +7,10 @@ import { Folder } from "@rapidmx/restapi";
  * `EasSyncKeyUtils.ts` (scoped by `mailboxUid` over the `Folder` collection, rather than `folderUid` over a
  * per-folder item collection the way `SyncCommand` will be).
  *
+ * **Keys**: an unknown `SyncKey` is answered with Status 9 ([MS-ASCMD] FolderSync: "synchronization key mismatch or
+ * invalid synchronization key"; the client restarts from `0`). The key issued before the current one is still
+ * accepted: the key itself encodes its cursor, so a retry simply recomputes that round's changes.
+ *
  * `folderClass` is supplied by the Mongo/SQL concrete subclasses, following the exact one-line-per-backend
  * pattern used throughout this library's other routes/jobs.
  *
@@ -21,5 +25,4 @@ export declare abstract class FolderSyncCommand<F extends Folder> implements Eas
     init(): Promise<void>;
     handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
     private folderToChangeElement;
-    private persistSyncKey;
 }

package/dist/types/commands/GetItemEstimateCommand.d.ts

@@ -1,8 +1,7 @@
 import { type WbxmlElement } from "../codec/WbxmlElement.js";
 import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
-/** Binds one MS-ASCMD `Class` value to the concrete entity class this command counts against - a lighter
- * version of `SyncCommand`'s own `SyncCollectionBinding` (no adapter needed at all, since `GetItemEstimate`
- * never serializes an item, only counts them). Supplied by the Mongo/SQL concrete subclasses. */
+/** Binds one MS-ASCMD `Class` value to the concrete entity class this command counts against. Supplied by the
+ * Mongo/SQL concrete subclasses. */
 export interface EstimateCollectionBinding {
     entityClass: any;
 }
@@ -12,32 +11,38 @@ export interface EstimateCollectionBinding {
  * consumes a `SyncKey` itself.
  *
  * The modern (14.0+) request/response reuses `WbxmlCodePage.AirSync`'s own `Collections`/`Collection`/`Class`/
- * `CollectionId`/`SyncKey` via `SWITCH_PAGE` rather than this page's own legacy (`Folders`/`Folder`/`FolderId`)
- * shape - see `WbxmlCodePages.ts`'s own doc comment on `WbxmlCodePage.ItemEstimate` for why, and
- * `ItemOperationsCommand.fetchMessage`'s identical cross-page-reuse precedent.
+ * `CollectionId`/`SyncKey` via `SWITCH_PAGE` rather than this page's own legacy (`Folders`/`Folder`/`FolderId`) shape.
  *
- * A `SyncKey` of `"0"` (or one this device has never synced this folder with before) reports the folder's
- * total live item count - what a first `Sync` would report as `Add`s. Otherwise reuses `EasSyncKeyUtils.
- * computeChanges()` (the same enumeration `SyncCommand` itself uses), capped at `DEFAULT_MAX_COUNT` - see its
- * own doc comment for why this is a real, documented approximation on a very active folder rather than a
- * precise unbounded count.
+ * The collection's `EasCollectionState` (the same per-device row `SyncCommand` keeps) decides the estimate: a
+ * `SyncKey` of `"0"` reports the folder's total live item count (what the first `Sync` would `Add`); the
+ * collection's current `SyncKey` runs `SyncCommand`'s own enumeration as a dry run (nothing persisted), capped at
+ * `mail:eas:item_estimate_max_count`; any other key is Status 2. A request without `Class` falls back to the class
+ * remembered for the collection, then to the folder's type.
  *
- * **ACL-checked like `Sync`**: `estimateCollection()` requires `ACLAction.READ` on the client-supplied
- * `CollectionId` before counting anything - without it, a crafted `CollectionId` belonging to another
- * mailbox's folder would return a real pending-change count for it. A denied folder is reported identically to
- * an unrecognized collection (`Status 2`), never distinguishable from "you don't have this collection at all".
+ * **Bounded like `Sync`**: at most `MAX_SYNC_COLLECTIONS` collections per request (more is a single Status 2), a
+ * `CollectionId` repeated within one request is estimated once, and a `SyncKey 0` count is capped at the same maximum.
+ *
+ * **ACL-checked like `Sync`**: `READ` on the client-supplied `CollectionId` is required before counting anything;
+ * a denied folder is reported identically to an unrecognized collection (`Status 2`).
  *
  * @author Jean-Philippe Steinmetz
  */
 export declare abstract class GetItemEstimateCommand implements EasCommandHandler {
     readonly command = "GetItemEstimate";
     protected abstract collectionBindings: Record<string, EstimateCollectionBinding>;
+    protected abstract folderClass: any;
+    protected abstract collectionStateClass: any;
+    protected abstract collectionChunkClass: any;
     private maxCount;
     private _objectFactory?;
     private aclUtils?;
     private repos;
+    private folderRepo?;
+    private collectionStateRepo?;
+    private collectionChunkRepo?;
     init(): Promise<void>;
     handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private statusResponse;
     private estimateCollection;
     private collectionElement;
 }

package/dist/types/commands/ItemOperationsCommand.d.ts

@@ -1,5 +1,7 @@
 import { type WbxmlElement } from "../codec/WbxmlElement.js";
 import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/** Most batches (of `mail:eas:itemoperations_batch_size` messages) one `EmptyFolderContents` deletes per request. */
+export declare const MAX_EMPTY_FOLDER_BATCHES = 20;
 /**
  * Handles EAS `ItemOperations`: `Fetch` (a `Message`'s full body or an `Attachment`'s binary content, by the
  * same `ServerId`/uid this library already exposes elsewhere) and `EmptyFolderContents`.
@@ -16,7 +18,10 @@ import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.
  * `MoveItems` command's per-message `SrcFldId`/`SrcMsgId`/`DstFldId` shape. Every `Message` sharing the
  * decoded `conversationId` across the whole mailbox (not just one folder) that the caller has `UPDATE` on is
  * relocated to `DstFldId`; one lacking permission is silently skipped rather than failing the whole move (a
- * conversation can legitimately span folders the caller doesn't control, e.g. a shared mailbox's Inbox). An
+ * conversation can legitimately span folders the caller doesn't control, e.g. a shared mailbox's Inbox). The
+ * `ConversationId` is looked up bounded and exact-matched in memory (it derives from sender-controlled headers), and
+ * each message's move follows `MessageMoveRules.planMessageMove` (never into Outbox, into Drafts only for drafts, out of
+ * Outbox cancels the scheduled send) - a refused message counts as failed. An
  * optional `MoveAlways` (a hint to keep auto-moving future messages in this conversation) is accepted but not
  * acted on - this library's `MailFilterRule` has no conversation-scoped condition to key an ongoing rule off
  * of, a documented simplification, not silent data loss (the move itself still happens).
@@ -28,15 +33,29 @@ import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.
  * command's original single-`Fetch` design, not a new gap introduced by adding multi-`Fetch` support.
  * - Only the "inline" delivery method is used (content embedded directly in the WBXML response) - the real
  * spec's "multipart" alternative (WBXML as one part, binary content as a separate part) is not implemented;
- * every attachment this library's own `ScanPipeline` already accepts is assumed to fit comfortably in memory
- * for one response, the same assumption `BaseAttachmentRoute.download()` already makes.
+ * the combined size of the bodies/attachments embedded in one response is capped at
+ * `mail:eas:itemoperations_max_response_bytes` (default 64 MB) - a Fetch that would exceed it gets Status 11
+ * ("data too large") instead of content. Attachment access is checked against the owning message's *current*
+ * folder (`Attachment.folderUid` is not updated when a message moves).
  * - `Options/BodyPreference`'s `Type`/`TruncationSize` are honored for a `Message` body fetch (plain text,
  * HTML, or - `Type 4` - the raw MIME source verbatim); byte-range fetching (`Range`) is not implemented.
  * - `EmptyFolderContents`'s `DeleteSubFolders` option is rejected outright rather than silently ignored -
  * recursive subfolder deletion is out of scope for this pragmatic subset; emptying a single folder's own
  * `Message`s is the common case this implements.
  *
- * `folderClass`/`messageClass`/`attachmentClass` are supplied by the Mongo/SQL concrete subclasses.
+ * **Bulk operations are bounded and per item**: `EmptyFolderContents` deletes at most `MAX_EMPTY_FOLDER_BATCHES`
+ * batches per request, and `Move` at most one batch; a message that fails to delete or move (e.g. a concurrent
+ * edit's version conflict) is skipped rather than failing the request, and the operation then reports Status 17
+ * (partial success) - or Status 3 when nothing at all succeeded - so the client can retry for the rest.
+ * `EmptyFolderContents` skips (as failed) a message whose send is in flight (`MessageMoveRules.hasLiveSendLease`).
+ *
+ * **Audit**: in a mailbox the caller doesn't own (restapi's `isNonOwnerAccess()` - an administrator or a delegate), a
+ * `Fetch` that returns a body or an attachment records one `MESSAGE_CONTENT_ACCESSED` entry per item, and
+ * `EmptyFolderContents` records one `MESSAGE_DELETE` entry per delete batch, listing the deleted message uids
+ * (`EasAuditLog`).
+ *
+ * `folderClass`/`messageClass`/`attachmentClass`/`mailboxClass`/`auditLogClass` are supplied by the Mongo/SQL concrete
+ * subclasses.
  *
  * @author Jean-Philippe Steinmetz
  */
@@ -45,13 +64,19 @@ export declare abstract class ItemOperationsCommand implements EasCommandHandler
     protected abstract folderClass: any;
     protected abstract messageClass: any;
     protected abstract attachmentClass: any;
+    protected abstract mailboxClass: any;
+    protected abstract auditLogClass: any;
     private _objectFactory?;
+    private config?;
+    private logger;
     private folderRepo?;
+    private mailboxRepo?;
     private messageRepo?;
     private attachmentRepo?;
     private blobStore?;
     private aclUtils?;
     private maxFetchesPerRequest;
+    private maxResponseBytes;
     private batchSize;
     init(): Promise<void>;
     handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;

package/dist/types/commands/MeetingResponseCommand.d.ts

@@ -1,21 +1,43 @@
 import { type WbxmlElement } from "../codec/WbxmlElement.js";
 import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/** Most `Request` elements one `MeetingResponse` may carry. */
+export declare const MAX_MEETING_RESPONSES = 100;
 /**
- * Handles EAS `MeetingResponse`: records the caller's own accept/tentative/decline response to a meeting on
- * the referenced `CalendarEvent`. `RequestId` is the same `Message`/`CalendarEvent.uid` this library already
- * exposes as `ServerId` elsewhere (Sync/FolderSync) - no separate lookup table is needed.
+ * Handles EAS `MeetingResponse`: records the caller's own accept/tentative/decline response to each meeting the
+ * request's `<Request>` elements name, each answered with its own `<Result>`.
  *
- * **Pragmatic subset**: only the first `<Request>` in the command is processed (the real spec allows several
- * per request, matching `Sync`'s own single-`Collection`-per-request scope in this library). A **decline**
- * soft-deletes the `CalendarEvent` (matching real Exchange behavior) rather than merely flipping the caller's
- * own `Attendee.responseStatus` - each attendee has their own row already (`CalendarEvent.mailboxUid` scopes
- * every event to a single mailbox, per this library's architecture), so deleting *this* row only removes the
- * meeting from the declining attendee's own calendar, leaving the organizer's and every other attendee's own
- * copy untouched. Accept/Tentative still update `Attendee.responseStatus` in place. The response omits
- * `CalendarId` for a decline either way, matching the spec's own convention, so a client relying on that
- * signal isn't misled into thinking a new item was created.
+ * **`RequestId`** is either the `CalendarEvent.uid` (a response from the calendar) or the `Message.uid` of the
+ * meeting request in the Inbox (a response from the mail view - what most clients send). For a message, the
+ * caller needs `READ` on its folder; its `text/calendar` part's `UID` is then resolved to the caller's own copy of
+ * the event (`icalUid` within the caller's mailbox) - looked up bounded (`boundIndexedValue`, as restapi stores it) and
+ * exact-matched in memory, since the UID is sender-controlled text a query parser could read as an operator.
  *
- * `calendarEventClass`/`mailboxClass` are supplied by the Mongo/SQL concrete subclasses.
+ * **Someone else's calendar**: whether a copy is the organizer's is judged against the event's own mailbox, not the
+ * caller's. A response to an event in another mailbox (a delegate with `UPDATE` on it) is refused with Status 2 when
+ * that event is its owner's organizer copy - it can only ever be an attendee copy. Updates are version-checked on both
+ * backends (`asEntity`).
+ *
+ * **Effect**: the caller must be an attendee and have `UPDATE` on the event's folder. Accept/Tentative update
+ * the caller's `Attendee.responseStatus`. A decline removes the caller's own copy of the event (matching Exchange)
+ * when the caller also has `DELETE` on the folder, and otherwise just records the declined status - a delegate
+ * with edit-only rights can't delete. Each mailbox has its own event row, so neither touches the organizer's or
+ * any other attendee's copy. `CalendarId` is omitted for a removed event. Since the caller's copy is an attendee's copy
+ * of someone else's meeting, neither write may look like the organizer acting to restapi's `MeetingSchedulingJob`:
+ * a removed copy is stamped `cancelNoticeSentAt` first (no CANCEL mailed as the organizer), and an updated copy keeps
+ * `inviteSequenceSent` equal to its `sequence` (no REQUEST).
+ *
+ * **Reply to the organizer**: in protocol 16.x the client asks the server to notify the organizer with
+ * `SendResponse`; when it's present an iTIP `REPLY` (built with restapi's `buildEventIcs`, the same payload
+ * `BaseCalendarEventRoute.respond` sends) is mailed from the caller's attendee address to the organizer,
+ * and a transport that accepts none of it (or rejects the organizer) is reported as Status 4 - the response itself is
+ * already recorded, so a retry only re-sends the reply. Without it (14.x clients send their own reply via `SendMail`) nothing is mailed, so the organizer
+ * never receives two replies.
+ *
+ * Failures are per request: an unknown/unresolvable meeting, a meeting the caller may not respond to, or a
+ * malformed `Request` gets Status 2 (indistinguishable, so nothing about other mailboxes leaks); a failed write
+ * Status 3.
+ *
+ * `calendarEventClass`/`mailboxClass`/`messageClass` are supplied by the Mongo/SQL concrete subclasses.
  *
  * @author Jean-Philippe Steinmetz
  */
@@ -23,10 +45,27 @@ export declare abstract class MeetingResponseCommand implements EasCommandHandle
     readonly command = "MeetingResponse";
     protected abstract calendarEventClass: any;
     protected abstract mailboxClass: any;
+    protected abstract messageClass: any;
     private _objectFactory?;
     private calendarEventRepo?;
     private mailboxRepo?;
+    private messageRepo?;
     private aclUtils?;
+    private blobStore?;
+    private mailTransport?;
+    private logger;
     init(): Promise<void>;
     handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private result;
+    private respond;
+    /** Resolves `requestId` to the caller's event: an event uid directly, or a meeting request message's
+     * `text/calendar` `UID` looked up among the caller's own mailbox's events. */
+    private resolveEvent;
+    /** The iCalendar `UID` of a meeting request message's `text/calendar` part, if it has one. */
+    private meetingUidOf;
+    /** Mails an iTIP `REPLY` for `attendee`'s response to the event's organizer. Returns `false` (after logging) when
+     * the transport threw or didn't accept the message for the organizer - checked the way restapi's `sendOrThrow`
+     * does, since every bundled transport reports a relay failure through `TransportResult.rejected` rather than
+     * throwing. */
+    private sendReply;
 }

package/dist/types/commands/MoveItemsCommand.d.ts

@@ -1,13 +1,23 @@
 import { type WbxmlElement } from "../codec/WbxmlElement.js";
 import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/** Most `Move` elements one `MoveItems` request may carry - more is rejected with HTTP 400. */
+export declare const MAX_MOVES_PER_REQUEST = 500;
 /**
  * Handles the standalone EAS `MoveItems` command: moves one or more `Message`s between folders in the caller's
- * own mailbox by `ServerId`/`uid`.
+ * own mailbox by `ServerId`/`uid`. A move never crosses mailboxes (the destination folder must belong to the
+ * message's own mailbox) and a request may carry at most `MAX_MOVES_PER_REQUEST` moves.
+ *
+ * Each move gets its own [MS-ASCMD] status: `3` success; `1` an unknown/unreadable message, or a `SrcFldId` that
+ * isn't where it lives (or can't be updated); `2` an unknown destination, one in another mailbox, one the caller
+ * can't create in, Outbox, or Drafts for a message that isn't already a draft (`MessageMoveRules.planMessageMove`);
+ * `4` source and destination are the same folder; `7` the update itself failed (e.g. a concurrent edit's version
+ * conflict - the update is version-checked on both backends), a send in flight, or the message already left Outbox as sent - one failing
+ * move never aborts the others. Moving a message out of Outbox cancels its scheduled send.
  *
  * **Pragmatic subset**: `Message` only - `Contacts`/`Calendar`/`Tasks` moves are rare in practice (unlike
  * `Message`, whose Inbox-to-subfolder filing is a real, common client action) and would each need their own
- * ACL/ownership verification path for comparatively little value; a client attempting one gets `Status 3`
- * rather than being silently ignored. `DstMsgId` in the response is always the same `uid` as `SrcMsgId` - this
+ * ACL/ownership verification path for comparatively little value; a client attempting one gets Status 1 (its
+ * `SrcMsgId` isn't a message) rather than being silently ignored. `DstMsgId` in the response is always the same `uid` as `SrcMsgId` - this
  * library never mints a new identifier on move, unlike a real Exchange server, which sometimes does.
  *
  * `messageClass`/`folderClass` are supplied by the Mongo/SQL concrete subclasses.