@rapidmx/activesync-plugin 1.0.0-beta.2

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

@@ -0,0 +1,32 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCollectionSyncAdapter } from "./EasCollectionSyncAdapter.js";
+import { type Task } from "@rapidmx/restapi";
+/**
+ * Maps `Task` to/from the EAS `Sync` `Tasks` collection class (MS-ASTASK).
+ *
+ * **Pragmatic subset**: only the `Utc*` (UTC Compact DateTime) variant of each date field is emitted, not the
+ * paired local-time variant MS-ASTASK also defines (`DueDate`/`StartDate` alongside `UtcDueDate`/
+ * `UtcStartDate`) - this library doesn't track a per-task timezone to correctly localize the non-UTC variant,
+ * and a real device already treats the `Utc*` field as authoritative. Recurring tasks are not synced (a task's
+ * `Recurrence` element mirrors Calendar's, itself already a pragmatic subset there - deferred further here).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class TasksSyncAdapter implements EasCollectionSyncAdapter<Task> {
+    readonly collectionClass = "Tasks";
+    toApplicationData(task: Task): WbxmlElement;
+    /**
+     * Reverse of `toApplicationData`. `DateCompleted` is never parsed back - it's `task.dateModified` echoed
+     * out, not an independent field this library's own `Task` model has room to store separately, so a client
+     * setting `Complete` is enough on its own. `ReminderSet="0"` (with no `ReminderTime`) is treated as an
+     * explicit "clear the reminder" signal (`reminderDate: null` in the returned partial, which - unlike
+     * simply omitting the key - does override an existing reminder when merged onto `existing` for a `Change`)
+     * since MS-ASTASK gives no other way to express removing a reminder; `UtcDueDate` has no equivalent
+     * explicit-clear signal and so can only be set, never cleared, via `Sync` - a real, narrower gap than
+     * `reminderDate`'s, documented here rather than silently accepted. `null`, not `undefined`: TypeORM's
+     * `UpdateQueryBuilder` silently drops any `undefined`-valued key from the generated SQL `SET` clause
+     * (confirmed by reading its source), so `undefined` here would leave a stale `reminderDate` in place on
+     * the SQL backend while correctly clearing it on Mongo - `null` clears it on both.
+     */
+    fromApplicationData(el: WbxmlElement): Partial<Task>;
+}

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

@@ -0,0 +1,7 @@
+import { EmailSyncAdapter } from "../EmailSyncAdapter.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class EmailSyncAdapterMongo extends EmailSyncAdapter {
+    protected labelClass: any;
+}

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

@@ -0,0 +1 @@
+export * from "./EmailSyncAdapterMongo.js";

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

@@ -0,0 +1,7 @@
+import { EmailSyncAdapter } from "../EmailSyncAdapter.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class EmailSyncAdapterSQL extends EmailSyncAdapter {
+    protected labelClass: any;
+}

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

@@ -0,0 +1 @@
+export * from "./EmailSyncAdapterSQL.js";

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

@@ -0,0 +1,45 @@
+/**
+ * WBXML code page index -> namespace name, per MS-ASWBXML §2.1.2.1 ("List of Code Pages"). A code page is
+ * WBXML's mechanism for reusing the single-byte tag-token space across many XML namespaces: a `SWITCH_PAGE`
+ * global token changes which of these tables subsequent tag bytes are looked up against.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare enum WbxmlCodePage {
+    AirSync = 0,
+    Contacts = 1,
+    Email = 2,
+    AirNotification = 3,
+    Calendar = 4,
+    Move = 5,
+    ItemEstimate = 6,
+    FolderHierarchy = 7,
+    MeetingResponse = 8,
+    Tasks = 9,
+    ResolveRecipients = 10,
+    ValidateCert = 11,
+    Contacts2 = 12,
+    Ping = 13,
+    Provision = 14,
+    Search = 15,
+    Gal = 16,
+    AirSyncBase = 17,
+    Settings = 18,
+    DocumentLibrary = 19,
+    ItemOperations = 20,
+    ComposeMail = 21,
+    Email2 = 22,
+    Notes = 23,
+    RightsManagement = 24,
+    Find = 25
+}
+/** Resolves a decoded tag byte's low 6 bits back into its tag name for the given code page. Falls back to a
+ * synthetic `"Unknown0x.."` name (rather than throwing) for a page/code this table doesn't recognize - a
+ * still-decodable, debuggable placeholder for a deferred code page or a future protocol version's new field,
+ * rather than failing the entire document over one unrecognized tag. */
+export declare function tagNameForCode(page: number, code: number): string;
+/** Resolves a tag name to its token byte (low 6 bits, before the content-flag bit is applied) for the given
+ * code page. Unlike `tagNameForCode()`, this throws on an unknown pair - encoding a tag this table has no
+ * token for is always a genuine programming error (an unregistered/deferred field), never legitimate input to
+ * tolerate. */
+export declare function codeForTagName(page: number, tag: string): number;

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

@@ -0,0 +1,33 @@
+import type { WbxmlElement } from "./WbxmlElement.js";
+/**
+ * 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.
+ *
+ * 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
+ * never uses) — safe here since every real EAS document sends the literal well-known value `1` ("unknown or
+ * missing"), which decodes identically either way.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class WbxmlDecoder {
+    private buf;
+    private pos;
+    private currentPage;
+    private depth;
+    decode(data: Buffer): WbxmlElement;
+    private readByte;
+    /** 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;
+    private readCString;
+    private readTagElement;
+    /** Reads a mixed sequence of child tag elements / an inline string / opaque binary content, up to (and
+     * consuming) the terminating `END` token — the body of one "has content" element. Also handles a
+     * `SWITCH_PAGE` appearing between sibling children, which applies to every subsequent sibling until
+     * either the next switch or the end of this content block (switching page is a standing instruction, not
+     * scoped to a single following tag). */
+    private readContentUntilEnd;
+}

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

@@ -0,0 +1,43 @@
+/**
+ * A minimal, tagged-tree representation of one WBXML element, decoupled from the wire format's binary token
+ * encoding — `WbxmlEncoder`/`WbxmlDecoder` are the only code that ever deals in raw bytes; every EAS command
+ * handler works against this tree.
+ *
+ * Deliberately does not model WBXML attributes: MS-ASWBXML's own algorithm description confirms ActiveSync
+ * never uses the attribute mechanism (every element's data is carried as child elements or inline text), so
+ * there is nothing for an `attrs` field to represent here.
+ *
+ * A given element is expected to carry exactly one of `children` (nested elements - the common case for a
+ * structural container like `Sync`/`Collection`), `text` (a single inline string value - the common case for
+ * a leaf field like `SyncKey`/`ServerId`), or `opaque` (raw binary content - used only for `ItemOperations`
+ * `Data` and similar binary payloads). Real ActiveSync XML is data-oriented, not document-oriented, so this
+ * library never needs to represent mixed content (an element with both nested tags and inline text).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export interface WbxmlElement {
+    /** The `WbxmlCodePage` this element's tag belongs to. */
+    page: number;
+    /** The tag name, as registered in `WbxmlCodePages.ts` for `page`. */
+    tag: string;
+    /** Nested elements, in document order. Empty for a leaf/empty element. */
+    children: WbxmlElement[];
+    /** Inline string content (WBXML `STR_I`), for a leaf element carrying a single text value. */
+    text?: string;
+    /** Raw binary content (WBXML `OPAQUE`), for a leaf element carrying binary data. */
+    opaque?: Buffer;
+}
+/** Constructs a structural element with nested children (e.g. `<Collection>...</Collection>`). */
+export declare function element(page: number, tag: string, children?: WbxmlElement[]): WbxmlElement;
+/** Constructs a leaf element carrying a single inline string value (e.g. `<SyncKey>1</SyncKey>`). */
+export declare function textElement(page: number, tag: string, text: string): WbxmlElement;
+/** Constructs a leaf element carrying raw binary content (e.g. `<Data>...</Data>` in `ItemOperations`). */
+export declare function opaqueElement(page: number, tag: string, opaque: Buffer): WbxmlElement;
+/** Finds the first direct child of `parent` with the given tag name, or `undefined` if none exists. Does not
+ * search recursively — WBXML/EAS field lookups are always relative to a specific known parent element. */
+export declare function findChild(parent: WbxmlElement, tag: string): WbxmlElement | undefined;
+/** Finds every direct child of `parent` with the given tag name (e.g. every `Collection` under
+ * `Collections`). */
+export declare function findChildren(parent: WbxmlElement, tag: string): WbxmlElement[];
+/** Shorthand for `findChild(parent, tag)?.text`, the common case of reading a leaf field's string value. */
+export declare function childText(parent: WbxmlElement, tag: string): string | undefined;

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

@@ -0,0 +1,20 @@
+import type { WbxmlElement } from "./WbxmlElement.js";
+/**
+ * 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).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class WbxmlEncoder {
+    private bytes;
+    private currentPage;
+    encode(root: WbxmlElement): Buffer;
+    private writeElement;
+    private writeStrI;
+    private writeOpaque;
+    /** Encodes `value` as a WBXML multi-byte unsigned integer (`mb_u_int32`): base-128 digits, most
+     * significant group first, every byte but the last carrying the 0x80 continuation bit. */
+    private writeMbUint;
+}

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

@@ -0,0 +1,50 @@
+import { type Message, RecoverableRepoUtils } from "@rapidmx/restapi";
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * 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
+ * referencing a pre-existing draft `Message`, unlike the webmail REST API's `POST /messages/:id/send` (see
+ * `BaseMessageRoute.send()`, which this class's `scanAndRelay()` call shares its scan-then-relay core with via
+ * `MailSendUtils.ts`).
+ *
+ * **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).
+ * - `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).
+ *
+ * `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).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class ComposeMailCommand implements EasCommandHandler {
+    abstract readonly command: string;
+    protected abstract folderClass: any;
+    protected abstract messageClass: any;
+    private _objectFactory?;
+    protected folderRepo?: RecoverableRepoUtils<any>;
+    protected messageRepo?: RecoverableRepoUtils<any>;
+    private blobStore?;
+    private mailTransport?;
+    private scanPipeline?;
+    private aclUtils?;
+    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. */
+    protected markOriginal(_ctx: EasCommandContext, _original: Message & {
+        uid: string;
+    }): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+}

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

@@ -0,0 +1,25 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+import { Folder } from "@rapidmx/restapi";
+/**
+ * Handles EAS `FolderSync`: enumerates `Add`/`Update`/`Delete`s for the caller's mailbox's `Folder` hierarchy
+ * since the device's last `FolderSync`, using the shared watermark-based cursor mechanism in
+ * `EasSyncKeyUtils.ts` (scoped by `mailboxUid` over the `Folder` collection, rather than `folderUid` over a
+ * per-folder item collection the way `SyncCommand` will be).
+ *
+ * `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.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class FolderSyncCommand<F extends Folder> implements EasCommandHandler {
+    readonly command = "FolderSync";
+    protected abstract folderClass: any;
+    private windowSize;
+    private _objectFactory?;
+    private folderRepo?;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private folderToChangeElement;
+    private persistSyncKey;
+}

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

@@ -0,0 +1,43 @@
+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. */
+export interface EstimateCollectionBinding {
+    entityClass: any;
+}
+/**
+ * Handles EAS `GetItemEstimate`: reports, per requested `<Collection>`, an estimated count of the
+ * `Add`/`Change`/`Delete`s a subsequent `Sync` of that collection would return - read-only, it never issues or
+ * 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.
+ *
+ * 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.
+ *
+ * **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".
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class GetItemEstimateCommand implements EasCommandHandler {
+    readonly command = "GetItemEstimate";
+    protected abstract collectionBindings: Record<string, EstimateCollectionBinding>;
+    private maxCount;
+    private _objectFactory?;
+    private aclUtils?;
+    private repos;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private estimateCollection;
+    private collectionElement;
+}

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

@@ -0,0 +1,72 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * 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`.
+ *
+ * Per the published [MS-ASCMD] `ItemOperations` request schema (confirmed directly, not assumed), the command
+ * is a strict choice of exactly three operations - `Fetch` (unbounded), `EmptyFolderContents`, and `Move` -
+ * with no fourth "write a new item" capability anywhere in it; `Store` is a required *child* of `Fetch`
+ * (`"Mailbox"` or `"DocumentLibrary"`, the same store-selector role it plays in `SearchCommand`), not a
+ * separate write/upload command as its name might suggest.
+ *
+ * **Pragmatic subset, deliberately not the full MS-ASCMD `ItemOperations` semantics**:
+ * - `Move` moves an entire *conversation* (by `ConversationId`, opaque binary - see `EmailSyncAdapter`'s
+ * `encodeConversationId`/`decodeConversationId`) to a destination folder - unrelated to the standalone
+ * `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
+ * 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).
+ * - `Store: "DocumentLibrary"` is rejected per-`Fetch` - matches `SearchCommand`'s own GAL-only scope decision;
+ * this library has no document-library model.
+ * - A `Fetch` failure (not found, no permission, malformed) aborts the whole request via an HTTP-level error
+ * rather than an embedded per-`Fetch` `Status` code the way `Sync`/`MoveItems`/`ResolveRecipients` report
+ * their own per-item failures - a deliberate, documented simplification carried over unchanged from this
+ * 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.
+ * - `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.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class ItemOperationsCommand implements EasCommandHandler {
+    readonly command = "ItemOperations";
+    protected abstract folderClass: any;
+    protected abstract messageClass: any;
+    protected abstract attachmentClass: any;
+    private _objectFactory?;
+    private folderRepo?;
+    private messageRepo?;
+    private attachmentRepo?;
+    private blobStore?;
+    private aclUtils?;
+    private maxFetchesPerRequest;
+    private batchSize;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private fetchMessage;
+    private emptyFolderContents;
+    /**
+     * Handles `ItemOperations`' `Move`: relocates every `Message` sharing a decoded `ConversationId` to
+     * `DstFldId`. Unlike `emptyFolderContents`/`fetchMessage` (which fail the whole request via a thrown
+     * `ApiError`), this reports failure through the embedded `Status` the same way `MoveItemsCommand` does for
+     * its own per-item results - a malformed/unresolvable `Move` is a normal outcome for this operation, not an
+     * exceptional one. Reports failure (`Status 3`) if not even one message was actually moved - including when
+     * every message sharing the conversation sits in a folder the caller lacks `UPDATE` on, which would
+     * otherwise silently fall through to a false "success" with nothing having moved.
+     */
+    private moveConversation;
+    private moveResponse;
+    private fetchAttachment;
+}

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

@@ -0,0 +1,32 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * 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.
+ *
+ * **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.
+ *
+ * `calendarEventClass`/`mailboxClass` are supplied by the Mongo/SQL concrete subclasses.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class MeetingResponseCommand implements EasCommandHandler {
+    readonly command = "MeetingResponse";
+    protected abstract calendarEventClass: any;
+    protected abstract mailboxClass: any;
+    private _objectFactory?;
+    private calendarEventRepo?;
+    private mailboxRepo?;
+    private aclUtils?;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+}

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

@@ -0,0 +1,29 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles the standalone EAS `MoveItems` command: moves one or more `Message`s between folders in the caller's
+ * own mailbox by `ServerId`/`uid`.
+ *
+ * **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
+ * 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.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class MoveItemsCommand implements EasCommandHandler {
+    readonly command = "MoveItems";
+    protected abstract messageClass: any;
+    protected abstract folderClass: any;
+    private _objectFactory?;
+    private messageRepo?;
+    private folderRepo?;
+    private aclUtils?;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private moveOne;
+    private responseElement;
+}

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

@@ -0,0 +1,33 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles EAS `Ping`: a long-poll HTTP request that blocks for up to `HeartbeatInterval` seconds waiting for a
+ * change in any of the client-specified folders, then reports which (if any) actually changed. No websocket
+ * needed - subscribes a plain, request-scoped Redis client (the same construction `BasePushRoute.connect()`
+ * uses, minus its own per-socket bookkeeping this one-shot request doesn't need) directly to the requested
+ * `folderUid` channels. Every `Message`/`CalendarEvent`/etc. mutation already publishes to exactly these
+ * channels via `BaseScopedChildRoute.notify()`/`RepoUtils`'s own push - `Ping` needs no new publish call site
+ * of its own, only a subscriber.
+ *
+ * Requested folder uids are filtered down to only those the caller currently has `READ` on before subscribing -
+ * matching every other command's ownership check on a client-supplied id, since without it a device could
+ * long-poll indefinitely on any folder uid it happens to know (including one it used to have legitimate access
+ * to and no longer does) and learn purely from this channel when that other mailbox's data changes.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class PingCommand implements EasCommandHandler {
+    readonly command = "Ping";
+    private redisConfig;
+    private minHeartbeatSeconds;
+    private maxHeartbeatSeconds;
+    private aclUtils?;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private statusResponse;
+    /** Subscribes to `folderUids` and resolves with whichever of them published a change first, or `[]` if
+     * `timeoutSeconds` elapses with no publish. A missing `datastores:events` config (Redis pub/sub not set up
+     * for this deployment) fails open to "no changes" rather than blocking forever or throwing - `Ping` is a
+     * best-effort low-latency notification path, not the only way a client ever discovers new mail (it will
+     * eventually poll a real `Sync`/`FolderSync` regardless). */
+    private waitForChange;
+}

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

@@ -0,0 +1,54 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles the two-request EAS `Provision` handshake (MS-ASPROV) every client must complete before any other
+ * command is honored (see `BaseEasRoute`'s provisioning gate), plus the three-step `RemoteWipe` sub-flow that
+ * rides the same command.
+ *
+ * **Policy issuance/enforcement**: the password/encryption requirements sent back in request 1's policy
+ * document are sourced from `@Config("mail:eas:provision:*")` (defaults below are permissive but not
+ * `0`/`false` across the board, unlike the old hardcoded document) - a deployment can tighten them without
+ * code changes. Enforcement itself is honest but shallow: request 2 must carry back `Status: 1` on its own
+ * `Policy` (a device that reports it could *not* apply the policy, or omits `Status` entirely, is rejected
+ * without provisioning) - this library does not itself verify the device's actual password/encryption state
+ * beyond trusting that self-reported status, matching MS-ASPROV's own protocol design (the wire protocol has
+ * no way for the server to inspect device state directly either).
+ *
+ * - **Request 1** (no `PolicyKey` in the body): mint a new policy key, store it on `DeviceSyncState` (not yet
+ * provisioned), and send back the policy document under that key. If a `RemoteWipe` was requested for this
+ * device (`DeviceSyncState.remoteWipeRequested`, set by an admin - see the remote-wipe route), skip normal
+ * policy issuance entirely and send the `RemoteWipe` directive instead.
+ * - **Request 2** (client echoes the `PolicyKey` back, acknowledging the policy): if the key matches what was
+ * minted in request 1 *and* the client's own `Status` is `1`, mark the device provisioned and re-confirm the
+ * same key; anything else (a stale/replayed key, a device that never actually saw request 1's response, or a
+ * device reporting it could not comply) is rejected without provisioning.
+ * - **RemoteWipe acknowledgement**: after wiping itself, a device sends a bare `<Provision><RemoteWipe>
+ * <Status>1</Status></RemoteWipe></Provision>` (no `Policies`). Detected first, ahead of the normal
+ * issue/acknowledge branching. Clears `remoteWipeRequested` and stamps `remoteWipeAcknowledgedAt` for audit,
+ * but deliberately leaves `provisioned` untouched (`false`, from when the wipe was requested) - the device
+ * must complete a genuine fresh Provision handshake to re-add the account, it does not fall straight back into
+ * "provisioned". `remoteWipeAccountOnly` is recorded for admin audit only; the wire directive sent to the
+ * device is identical either way (a real "wipe just this account's data" vs. "wipe the whole device"
+ * distinction would require an MDM-capable client extension this library doesn't implement).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class ProvisionCommand implements EasCommandHandler {
+    readonly command = "Provision";
+    private passwordEnabled;
+    private minPasswordLength;
+    private maxFailedAttempts;
+    private requireDeviceEncryption;
+    private allowSimplePassword;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    /** Request 1: mint and store a new policy key, send the policy document - or, if a remote wipe is
+     * pending for this device, the `RemoteWipe` directive instead. */
+    private issuePolicy;
+    /** Request 2: the client acknowledges the policy key it was handed in request 1, self-reporting whether
+     * it actually applied the policy via its own `Status`. */
+    private acknowledgePolicy;
+    /** The device has wiped itself and is acknowledging - clear the pending flag but leave `provisioned`
+     * alone (still `false`, from when the wipe was requested) so a genuine re-provision is required. */
+    private acknowledgeRemoteWipe;
+    private persist;
+}

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

@@ -0,0 +1,36 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles EAS `ResolveRecipients`: resolves each `<To>` value (a display name, partial name, or address) the
+ * client is unsure how to reach against the mailbox's own `Contact` (GAL) store - the same substring-match
+ * approach `SearchCommand` uses for its own `Store Name="GAL"` lookups, duplicated rather than shared (small
+ * enough, and specific enough to each command's own surrounding logic, that extracting a shared utility for two
+ * call sites isn't worth a new cross-command dependency). Both use `RepoUtils`' `regex(...)` operator (not
+ * `like(...)`, which compiles a glob pattern under `@rapidrest/service-core` ^2.0 - anchored, and with no escape
+ * for a literal `*`/`?`): `StringUtils.escapeRegExp(value)` gives a genuine, unanchored literal-substring match
+ * with no residual wildcard ambiguity, matching the same fix already applied to the `mapi` plugin's own
+ * identical GAL-search gap.
+ *
+ * **Pragmatic subset**: no free-busy `Availability`, no S/MIME `Certificates`/`Options` handling at all - this
+ * command's real-world use is overwhelmingly enterprise S/MIME certificate lookup, which this library doesn't
+ * implement elsewhere either (`ComposeMailCommand` sends plain MIME, never signed/encrypted). A `<To>` value
+ * that already looks like an email address (`LOOKS_LIKE_EMAIL`) is echoed straight back as its own single
+ * exact match rather than searched for, matching a real client's own common case of resolving an address it
+ * already typed correctly.
+ *
+ * `contactClass` is supplied by the Mongo/SQL concrete subclasses.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class ResolveRecipientsCommand implements EasCommandHandler {
+    readonly command = "ResolveRecipients";
+    protected abstract contactClass: any;
+    private maxMatches;
+    private _objectFactory?;
+    private contactRepo?;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private resolveOne;
+    private recipientElement;
+    private responseElement;
+}