@rapidmx/mapi-plugin 1.0.0-beta.3 → 1.0.0-beta.5

package/dist/types/rop/RepoPaging.d.ts

@@ -0,0 +1,30 @@
+import type { RepoUtils } from "@rapidrest/service-core";
+import type { ExecuteBudget } from "./ExecuteBudget.js";
+/** `RepoUtils.find()`'s own largest page. */
+export declare const REPO_PAGE_SIZE = 1000;
+/** The most rows gathered by `findAllCapped`. */
+export declare const MAX_COLLECTION_ROWS = 10000;
+/** A sort order in `RepoUtils` query syntax, e.g. `{ receivedDate: "DESC", uid: "ASC" }`. Always end with a
+ * unique field so pages don't overlap or skip rows that tie on the leading fields. */
+export type RepoSort = Record<string, "ASC" | "DESC">;
+/**
+ * Fetches one page. `limit`/`page`/`sort` go in both the query (what the SQL query builder reads) and the options
+ * (what Mongo reads); without them each backend silently returns its own 100-row default in an unspecified order.
+ *
+ * With a `budget`, the query is charged before it runs and the rows it returned right after, so a request past its
+ * `ExecuteBudget` stops before the next query.
+ */
+export declare function findPage<T>(repo: RepoUtils<any>, query: Record<string, any>, sort: RepoSort, page: number, pageSize?: number, budget?: ExecuteBudget): Promise<T[]>;
+/**
+ * Fetches every row matching `query`, in `sort` order, up to `cap` rows. `truncated` is `true` when more rows may
+ * exist past the cap.
+ */
+export declare function findAllCapped<T>(repo: RepoUtils<any>, query: Record<string, any>, sort: RepoSort, cap?: number, budget?: ExecuteBudget): Promise<{
+    items: T[];
+    truncated: boolean;
+}>;
+/**
+ * Fetches the rows at positions `[start, start + count)` of `query` in `sort` order, reading only the pages that
+ * window touches.
+ */
+export declare function findWindow<T>(repo: RepoUtils<any>, query: Record<string, any>, sort: RepoSort, start: number, count: number, budget?: ExecuteBudget): Promise<T[]>;

package/dist/types/rop/RestapiRules.d.ts

@@ -0,0 +1,32 @@
+import { type QueryLiteral, type RepoUtils } from "@rapidrest/service-core";
+/** The longest value `boundIndexedValue()` stores verbatim - restapi's `MAX_INDEXED_VALUE_LENGTH`. */
+export declare const MAX_INDEXED_VALUE_LENGTH = 255;
+/**
+ * restapi's `boundIndexedValue`: `value` unchanged when it's at most `MAX_INDEXED_VALUE_LENGTH` characters, otherwise
+ * `sha256:<64 hex digits>` of its UTF-8 bytes. restapi stores `CalendarEvent.icalUid` (and `Message.messageId`/
+ * `conversationId`) this way, so a lookup by one of those identifiers has to bound its value the same way to match.
+ */
+export declare function boundIndexedValue<T extends string | null | undefined>(value: T): T;
+/**
+ * restapi's `asEntity`: `row` as an instance of `repo`'s model class. Before service-core 2.1.0, `RepoUtils.update()`
+ * only enforced its optimistic lock when `existing instanceof BaseEntity`, and the Mongo backend's `find()`/`findOne()`
+ * return plain documents, so passing one straight through turned a versioned update into an unconditional overwrite.
+ * 2.1.0 also locks plain documents carrying a numeric `version`, so this is now defence in depth, kept while restapi
+ * keeps its own copy. SQL rows are already instances and pass through as they are.
+ */
+export declare function asEntity<T>(repo: RepoUtils<any>, row: T): T;
+/**
+ * A `RepoUtils` query value that always matches `value` literally: service-core's `ModelUtils.literal()`, so a
+ * client- or sender-supplied value like `ne(x)` is never read as an operator and `me`/`null`/numeric strings are not
+ * substituted or coerced. Callers still compare the returned rows' field against `value` themselves.
+ */
+export declare function literalQueryValue(value: string): QueryLiteral;
+/**
+ * restapi `MeetingSchedulingJob`'s eligibility rule (`jobs/MeetingSchedulingJob.ts`, `processInviteCandidates`): `true`
+ * while the job will still send invites for `event`'s current revision, i.e. its `inviteSequenceSent` is unset or
+ * differs from its `sequence`. Keep in sync with that job.
+ */
+export declare function isInvitePending(event: {
+    sequence?: number;
+    inviteSequenceSent?: number | null;
+}): boolean;

package/dist/types/rop/RopCreateMessageHandler.d.ts

@@ -19,5 +19,6 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  */
 export declare class RopCreateMessageHandler implements RopHandler {
     readonly ropId = 6;
+    readonly responseHandleIndexOffset = 3;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
 }

package/dist/types/rop/RopDeleteFolderHandler.d.ts

@@ -1,24 +1,33 @@
 import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
 import type { RopContext, RopHandler } from "./RopHandler.js";
+/** The deepest subfolder nesting a recursive delete walks. */
+export declare const MAX_FOLDER_DEPTH = 32;
+/** The most folders one recursive delete removes. */
+export declare const MAX_FOLDERS_PER_DELETE = 1000;
+/** The most items (messages, events, contacts, tasks) one `RopDeleteFolder` deletes. Past this the ROP stops,
+ * reports `PartialCompletion`, and leaves the folders that still hold items in place; the client can retry. */
+export declare const MAX_ITEMS_PER_DELETE = 10000;
 /**
- * `RopDeleteFolder` (`[MS-OXCFOLD]`/`[MS-OXCROPS]`, RopId `0x1D`): deletes a folder by `FolderId`. Reuses
- * `RecoverableRepoUtils.delete()` exactly as-built in Phase 2 for `Folder`/`Message`/`CalendarEvent` - see
- * `RopDeleteMessagesHandler.ts`'s own doc comment for why that matters (EAS's watermark-based incremental
- * delete detection depends on it).
+ * `RopDeleteFolder` (`[MS-OXCFOLD]`/`[MS-OXCROPS]`, RopId `0x1D`): deletes a folder by `FolderId`, via
+ * `RecoverableRepoUtils.delete()` - see `RopDeleteMessagesHandler.ts`'s own doc comment for why that matters (EAS's
+ * watermark-based incremental delete detection depends on it).
  *
- * **Real spec semantics honored, not simplified away**: per `[MS-OXCFOLD]`, `RopDeleteFolder` only operates on
- * an empty folder by default - `DEL_MESSAGES` must be set to also delete the folder's own messages/calendar
- * events/contacts/tasks, and `DEL_FOLDERS` to also delete (recursively) its subfolders; a non-empty folder
- * deleted without the matching flag fails rather than silently cascading. `DELETE_HARD_DELETE` maps directly
- * onto `RepoDeleteOptions.purge` - real, exact semantic overlap with this library's own soft-delete model, not
- * a coincidence this codec papers over.
+ * **Real spec semantics honored**: `RopDeleteFolder` only operates on an empty folder by default - `DEL_MESSAGES`
+ * must be set to also delete the folder's own messages/calendar events/contacts/tasks, and `DEL_FOLDERS` to also
+ * delete (recursively) its subfolders; a non-empty folder deleted without the matching flag fails rather than
+ * silently cascading.
  *
- * **Contacts/Tasks folders**: emptiness is checked against `contactRepo`/`taskRepo` alongside `messageRepo`/
- * `calendarEventRepo`, and both are included in the delete cascade - a `CONTACTS`/`TASKS` folder's real content
- * lives in those repos (see `ContactTarget.ts`/`TaskTarget.ts`), not `messageRepo`, so checking only the latter
- * would let a non-empty Contacts/Tasks folder be deleted without `DEL_MESSAGES` and orphan its rows. Guarded
- * with `context.contactRepo`/`taskRepo` presence checks the same way `RopGetContentsTableHandler` does, since
- * `RopContext`'s doc comment documents both as optional.
+ * **Always a soft delete.** `DELETE_HARD_DELETE` is ignored. A permanent delete has to go through restapi's legal
+ * hold check first (the REST routes call `LegalHoldUtils.assertNotOnLegalHold()` for `purge=true`), and that helper
+ * isn't part of `@rapidmx/restapi`'s public exports. A soft-deleted item stays recoverable and discoverable, which is
+ * exactly what a hold requires, so MAPI never purges. Each deleted message is audited as `MESSAGE_DELETE`, like the
+ * REST message route.
+ *
+ * **Bounded.** The subfolder tree is walked iteratively with a visited set (a corrupt `parentFolderUid` cycle
+ * can't loop), at most `MAX_FOLDER_DEPTH` deep and `MAX_FOLDERS_PER_DELETE` wide, and only through folders in the
+ * caller's own mailbox. Items are fetched in explicit, paged queries (a bare `find()` stops at 100 rows, which used
+ * to leave items behind in a folder that was then deleted), up to `MAX_ITEMS_PER_DELETE`. Every query and delete is
+ * charged to the request's `ExecuteBudget` before it runs, so repeating this ROP can't multiply the walk unbounded.
  *
  * The request's own `InputHandleIndex` (nominally the *parent* folder of the one being deleted) is validated to
  * be a real, open folder handle but not cross-checked against the target folder's actual `parentFolderUid` -
@@ -30,9 +39,15 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
 export declare class RopDeleteFolderHandler implements RopHandler {
     readonly ropId = 29;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
-    /** Cascades a `DEL_FOLDERS` delete into `folderUid`'s own messages/calendar events/subfolders before
-     * deleting it - this data model's folder hierarchy is a plain parent-pointer tree (never a graph), so
-     * unbounded recursion here needs no cycle protection, the same assumption `FolderTarget.resolveFolderChildren`
-     * already makes. */
-    private deleteFolderRecursive;
+    private writeFailure;
+    /** The repos a folder's items can live in, skipping the optional ones the context doesn't have. */
+    private itemRepos;
+    private hasItems;
+    /**
+     * `rootUid` and every folder below it in the caller's mailbox, children before their parents, or `undefined` when
+     * the tree is deeper than `MAX_FOLDER_DEPTH` or has more than `MAX_FOLDERS_PER_DELETE` folders.
+     */
+    private collectSubtree;
+    /** Soft-deletes `folderUid`'s items within `budget`. Returns `false` if items remain once the budget is spent. */
+    private deleteItems;
 }

package/dist/types/rop/RopDeleteMessagesHandler.d.ts

@@ -1,5 +1,12 @@
 import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
 import type { RopContext, RopHandler } from "./RopHandler.js";
+/** Audits a message deleted through MAPI with the same `MESSAGE_DELETE` entry the REST message route records. */
+export declare function auditMessageDelete(context: RopContext, message: {
+    uid: string;
+    mailboxUid: string;
+    subject?: string;
+    folderUid: string;
+}): Promise<void>;
 /**
  * `RopDeleteMessages` (`[MS-OXCMSG]`/`[MS-OXCROPS]`, RopId `0x1E`): deletes one or more messages by `MessageId`
  * from an already-open folder handle. Reuses `RecoverableRepoUtils.delete()` exactly as-built in Phase 2 - the

package/dist/types/rop/RopFastTransferSourceCopyPropertiesHandler.d.ts

@@ -20,5 +20,6 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  */
 export declare class RopFastTransferSourceCopyPropertiesHandler implements RopHandler {
     readonly ropId = 105;
+    readonly responseHandleIndexOffset = 3;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
 }

package/dist/types/rop/RopFastTransferSourceCopyToHandler.d.ts

@@ -20,5 +20,6 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  */
 export declare class RopFastTransferSourceCopyToHandler implements RopHandler {
     readonly ropId = 77;
+    readonly responseHandleIndexOffset = 3;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
 }

package/dist/types/rop/RopFastTransferSourceGetBufferHandler.d.ts

@@ -3,21 +3,20 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
 /**
  * `RopFastTransferSourceGetBuffer` (`[MS-OXCFXICS]`/`[MS-OXCROPS]`, RopId `0x4E`): pages the FastTransfer
  * stream a prior `RopFastTransferSourceCopyTo`/`CopyProperties` built (`FastTransferStream.ts`) out of its
- * `"fastTransfer"` handle, `BufferSize` bytes at a time (or the entire remaining buffer, capped to
- * `MAX_TRANSFER_BUFFER_SIZE`, for the `0xBABE` "server-determined" sentinel - `MaximumBufferSize`, present only
- * in that case, is decoded to advance the reader correctly but not honored, since honoring it would mean
- * returning *more* than one chunk can carry, not less). Reports `Done` once the whole buffer has been returned
- * across one or more calls, `Partial` otherwise - `NoRoom` and `Error` are never produced (a `"fastTransfer"`
- * handle, once created, always has a complete, already-valid buffer to page from).
+ * `"fastTransfer"` handle, `BufferSize` bytes at a time. For the `0xBABE` "server-determined" sentinel the server
+ * picks the size, up to the client's `MaximumBufferSize`.
  *
- * `BackoffTime` is never emitted (this pragmatic subset never returns the one `ReturnValue` that field is
- * conditional on), and the failure path (`ERROR_INVALID_OBJECT`) omits every field after `ReturnValue` entirely
- * - the same "just the fixed header, no success-only tail" shape every other failing handler in this pragmatic
- * subset already uses, not a specific claim about the real spec's own error-path byte layout.
+ * Every chunk is also held to the room left in this request's ROP output buffer (`context.ropOutputRemaining`) and
+ * the 16-bit `TransferBufferSize`. Reports `Done` once the whole stream has been returned, `Partial` otherwise, and
+ * `NoRoom` when the output buffer has no space for any bytes this time (the client asks again in a new request).
+ *
+ * Fails with `MAPI_E_TOO_BIG` when a stream that had to be rebuilt is too large, and with `MAPI_E_CALL_FAILED` when
+ * the stream was lost part-way through (see `loadFastTransferBuffer`) - never with bytes from a different stream.
+ * Failure responses carry only `ReturnValue`, like every other failing handler here. `BackoffTime` is never emitted.
  *
  * @author Jean-Philippe Steinmetz
  */
 export declare class RopFastTransferSourceGetBufferHandler implements RopHandler {
     readonly ropId = 78;
-    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
 }

package/dist/types/rop/RopGetContentsTableHandler.d.ts

@@ -5,27 +5,21 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  * messages, producing a new `"table"` Server object handle `RopSetColumns`/`RopQueryRows` reference by
  * `InputHandleIndex` - the exact same request/response shape as `RopGetHierarchyTable` (confirmed identical
  * field-by-field against `[MS-OXCROPS]`'s own request-buffer page, differing only in `RopId`), just listing
- * messages instead of child folders. `RopSetColumns`/`RopQueryRows` themselves need no changes at all to
- * support this - they already operate generically on whatever `rows`/`columns` a table handle carries,
- * dispatching to `FolderTarget`'s or `MessageTarget`'s resolvers by row-target prefix (`"folder:"`/`"virtual:"`
- * vs `"message:"`).
+ * messages instead of child folders.
+ *
+ * The table holds no rows. It records which kind of item the folder contains (`contentsKind`, decided once here
+ * from the folder's own `type`: Calendar folders list `"calendarEvent:<uid>"` rows, Contacts `"contact:<uid>"`,
+ * Tasks `"task:<uid>"`, everything else `"message:<uid>"`), and `RopQueryRows` reads each requested window from
+ * the database - see `ContentsTable.ts`.
  *
  * A folder's contents table is only ever non-empty for a real folder (`"folder:<uid>"`) - the virtual special
  * folders (`RopLogonHandler`'s own doc comment) have no real backing row to hold messages under, so opening a
  * contents table on one always yields an empty table rather than an error.
  *
- * **Calendar folders** (`Folder.type === FolderType.CALENDAR`) list `"calendarEvent:<uid>"` rows resolved via
- * `calendarEventRepo` instead of `"message:<uid>"` rows - a single table handle only ever holds one kind of
- * row, decided once here by checking the folder's own `type`, exactly the same "resolve by target-string
- * prefix downstream" design `MessageTarget`/`FolderTarget` already use for their own rows. **Contacts and
- * Tasks** folders (`FolderType.CONTACTS`/`TASKS`) list `"contact:<uid>"`/`"task:<uid>"` rows the same way, via
- * `contactRepo`/`taskRepo` - empty (rather than an error) when the context has neither wired up, the same
- * optional-repo degradation `RopContext`'s own doc comment describes.
- *
  * @author Jean-Philippe Steinmetz
  */
 export declare class RopGetContentsTableHandler implements RopHandler {
     readonly ropId = 5;
+    readonly responseHandleIndexOffset = 3;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
-    private resolveRows;
 }

package/dist/types/rop/RopGetHierarchyTableHandler.d.ts

@@ -13,5 +13,6 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  */
 export declare class RopGetHierarchyTableHandler implements RopHandler {
     readonly ropId = 4;
+    readonly responseHandleIndexOffset = 3;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
 }

package/dist/types/rop/RopHandler.d.ts

@@ -1,8 +1,10 @@
 import type { RepoUtils } from "@rapidrest/service-core";
-import type { BlobStore } from "@rapidmx/restapi";
+import type { AuditLogParams, BlobStore } from "@rapidmx/restapi";
 import type { ScanPipeline } from "@rapidmx/restapi/scan";
 import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
 import type { MapiSessionContext } from "../MapiSessionManager.js";
+import type { ExecuteBudget } from "./ExecuteBudget.js";
+import { type HandleDataStore } from "./HandleDataCache.js";
 /**
  * Everything a `RopHandler` needs beyond the raw ROP bytes it decodes itself. `folderRepo`/`mailboxRepo` are
  * built once by `BaseMapiEmsmdbRoute` (not by each handler, unlike EAS's per-command repo pattern - MAPI's ROPs
@@ -52,7 +54,36 @@ export interface RopContext {
     blobStore: BlobStore;
     scanPipeline: ScanPipeline;
     mailTransport: any;
+    /** Records an audit log entry as the calling user, the same way the REST routes do. Optional like the repos
+     * above: absent when the route has no audit log class configured, in which case nothing is recorded. */
+    audit?: (params: AuditLogParams) => Promise<void>;
+    /** Recomputes, re-caches and publishes the given folders' `unreadCount`/`totalCount` - restapi's
+     * `refreshFolderCounts()` (`@rapidmx/restapi`), bound to this route's own `messageRepo`/`folderRepo`/`folderClass`/
+     * `notificationUtils`. `Folder.unreadCount`/`totalCount` are a cache restapi's own writes keep fresh (see
+     * `FolderCountUtils.ts`'s module doc comment); a handler that adds, deletes or moves a `Message` row through
+     * `context.messageRepo` itself - never through a `BaseFolderRoute`/`BaseMessageRoute` this library already refreshes
+     * after - must call this for every folder it touched, or Outlook's own folder pane (which reads
+     * `PidTagContentCount`/`PidTagContentUnreadCount` straight off the stored fields, not derived on read - see
+     * `PropertyResolvers.ts`/`FolderTarget.ts`) goes stale. `bumpSyncKey` should be `true` when a message was added to a
+     * folder (restapi's own convention - see `refreshFolderCounts()`'s doc comment), and left unset for a plain
+     * deletion or status change. Always present in real use (`BaseMapiEmsmdbRoute.dispatch()` populates it
+     * unconditionally); optional here only so existing `RopContext`-literal test fixtures that predate this need no
+     * new field, the same reasoning `contactRepo`/`taskRepo`/`labelRepo` above already documents. */
+    notifyFolderCounts?: (folderUids: Iterable<string | undefined | null>, options?: {
+        bumpSyncKey?: boolean;
+    }) => Promise<void>;
+    /** Shared storage for FastTransfer streams and write-stream chunks. Absent in unit tests, where
+     * `defaultHandleDataStore` (this process only) is used - see `handleDataStoreOf`. */
+    handleData?: HandleDataStore;
+    /** This request's work budget, set by `dispatchRops`. Absent when a handler runs on its own. */
+    budget?: ExecuteBudget;
+    /** The bytes still free in this request's ROP output buffer for the current ROP's response, set by
+     * `dispatchRops` before each ROP. Handlers returning variable-size data (`RopReadStream`,
+     * `RopFastTransferSourceGetBuffer`, `RopQueryRows`) shrink their response to fit. Absent means unlimited. */
+    ropOutputRemaining?: number;
 }
+/** The `HandleDataStore` a handler should use for `context`. */
+export declare function handleDataStoreOf(context: Pick<RopContext, "handleData">): HandleDataStore;
 /**
  * One class per ROP, mirroring `EasCommandHandler`'s exact one-class-per-command convention. A handler owns
  * its own request/response wire format entirely - decoding whatever fields follow its own `RopId` byte from
@@ -63,5 +94,13 @@ export interface RopContext {
 export interface RopHandler {
     /** The `RopId` byte this handler processes (e.g. `0xFE` for `RopLogon`). */
     readonly ropId: number;
+    /** Where the handle index a failure response echoes sits in the request, counting the `RopId` byte as 0. Most
+     * ROPs echo `InputHandleIndex` (2, the default); ROPs that create an object echo `OutputHandleIndex` (3). Used
+     * by `RopDispatcher` to write a failure response when the handler throws. */
+    readonly responseHandleIndexOffset?: number;
+    /** Zero bytes a failure response carries after `ReturnValue` (`RopReadStream`'s `DataSize`, ...). */
+    readonly failureTailBytes?: number;
+    /** `true` for a ROP that never has a response (`RopRelease`), so a failure writes nothing either. */
+    readonly hasNoResponse?: boolean;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void> | void;
 }

package/dist/types/rop/RopOpenFolderHandler.d.ts

@@ -15,5 +15,6 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  */
 export declare class RopOpenFolderHandler implements RopHandler {
     readonly ropId = 2;
+    readonly responseHandleIndexOffset = 3;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
 }

package/dist/types/rop/RopOpenMessageHandler.d.ts

@@ -23,5 +23,6 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  */
 export declare class RopOpenMessageHandler implements RopHandler {
     readonly ropId = 3;
+    readonly responseHandleIndexOffset = 3;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
 }

package/dist/types/rop/RopOpenStreamHandler.d.ts

@@ -23,5 +23,6 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  */
 export declare class RopOpenStreamHandler implements RopHandler {
     readonly ropId = 43;
+    readonly responseHandleIndexOffset = 3;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
 }

package/dist/types/rop/RopQueryRowsHandler.d.ts

@@ -1,5 +1,8 @@
 import { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
 import type { RopContext, RopHandler } from "./RopHandler.js";
+/** The most rows one `RopQueryRows` returns. Fewer rows than requested is normal table paging: the client asks
+ * again from the new cursor position. */
+export declare const MAX_ROWS_PER_QUERY = 500;
 /**
  * `RopQueryRows` (`[MS-OXCTABL]`/`[MS-OXCROPS]`): fetches up to `RowCount` rows from an already-configured
  * table (`RopGetHierarchyTable` + `RopSetColumns`), advancing the table's cursor. Confirmed field-by-field

package/dist/types/rop/RopReadStreamHandler.d.ts

@@ -5,7 +5,8 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  * `ByteCount` is the `0xBABE` sentinel) bytes from an already-opened stream (`RopOpenStream`), advancing the
  * stream's read position - clamped to `MAX_DATA_SIZE` (`0xFFFF`) regardless of what the client asked for, since
  * the response's own `DataSize` field can't carry more than that; a client wanting more of a large body simply
- * calls `RopReadStream` again from the advanced `streamPosition`, the same paging behavior real Exchange uses.
+ * calls `RopReadStream` again from the advanced `streamPosition`, the same paging behavior real Exchange uses. It is
+ * likewise held to the room left in the request's ROP output buffer (`context.ropOutputRemaining`).
  * Unlike most other ROPs in this pragmatic subset, `[MS-OXCROPS]` documents only one combined response-buffer
  * shape for this ROP (no separate Success/Failure pages) - `DataSize`/`Data` are always present, `DataSize = 0`
  * (empty `Data`) standing in for the failure case rather than the fields being omitted entirely.
@@ -14,5 +15,6 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  */
 export declare class RopReadStreamHandler implements RopHandler {
     readonly ropId = 44;
+    readonly failureTailBytes = 2;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
 }

package/dist/types/rop/RopReleaseHandler.d.ts

@@ -10,5 +10,6 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  */
 export declare class RopReleaseHandler implements RopHandler {
     readonly ropId = 1;
+    readonly hasNoResponse = true;
     handle(reader: BufferReader, _writer: BufferWriter, context: RopContext): void;
 }

package/dist/types/rop/RopSaveChangesMessageHandler.d.ts

@@ -1,3 +1,4 @@
+import { type CalendarEvent } from "@rapidmx/restapi";
 import { BufferReader, type BufferWriter } from "../codec/BufferCursor.js";
 import type { RopContext, RopHandler } from "./RopHandler.js";
 /**
@@ -25,7 +26,11 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  * `"calendarEvent:<uid>"`) a real `CalendarEvent` row, so a subsequent `RopGetPropertiesSpecific` can read it
  * back before `RopSubmitMessage` is ever called (a calendar item must exist as soon as it's saved, the same way
  * a real Exchange server behaves - unlike a mail draft, which this pragmatic subset never persists at all until
- * Submit).
+ * Submit). Saving never invites anyone: a saved revision is stamped as already handled (`inviteSequenceSent =
+ * sequence`), so restapi's `MeetingSchedulingJob` skips it until `RopSubmitMessageHandler.submitAppointment` asks for
+ * invites. Attendees of a submitted meeting are then mailed by that job, which is why a meeting is capped at
+ * `MAX_RECIPIENTS_PER_MESSAGE` attendees here. Client-supplied times and reminder minutes that don't parse are ignored (the field keeps its
+ * existing or default value) rather than stored as `Invalid Date`/`NaN`, and an update is versioned (`asEntity`).
  *
  * @author Jean-Philippe Steinmetz
  */
@@ -39,6 +44,16 @@ export declare class RopSaveChangesMessageHandler implements RopHandler {
      * below - the write-side mirror of `PropertyResolvers.calendarEventValueFor`'s read-side switch. A field the
      * client never set (e.g. no `RopSetProperties` call touched `PidLidBusyStatus`) falls back to the existing
      * row's own value on an update, or the entity class's own default on a fresh create.
+     *
+     * Returns `undefined`, saving nothing, for more than `MAX_RECIPIENTS_PER_MESSAGE` attendees: restapi's
+     * `MeetingSchedulingJob` mails every attendee of a saved meeting.
      */
     private saveAppointment;
 }
+/**
+ * `true` when an update changes what attendees were invited to: the start or end time, location, recurrence, or
+ * who is invited. The same fields restapi's `BaseCalendarEventRoute.update()` bumps `sequence` for (a MAPI save
+ * never sets `status`), so an edit made in Outlook is re-sent to attendees and supersedes their copy (RFC 5546
+ * `SEQUENCE`) exactly like one made through REST.
+ */
+export declare function isSchedulingRelevantChange(existing: Pick<CalendarEvent, "startDate" | "endDate" | "location" | "recurrenceRule" | "attendees">, updated: Pick<CalendarEvent, "startDate" | "endDate" | "location" | "recurrenceRule" | "attendees">): boolean;

package/dist/types/rop/RopSubmitMessageHandler.d.ts

@@ -1,10 +1,6 @@
 import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
-import type { RopContext, RopHandler } from "./RopHandler.js";
-/** Splits a `PidTagDisplayTo`/`Cc`/`Bcc`-style string on the semicolons real Outlook separates recipients
- * with (also tolerating commas, in case a client or test harness uses that convention instead), trimming and
- * dropping empty entries. Exported since `RopSaveChangesMessageHandler.ts` reads the same accumulated
- * `PidTagDisplayTo`/`Cc` draft properties to build a Calendar item's attendee list. */
-export declare function parseAddressList(value: string | undefined): string[];
+import { type RopContext, type RopHandler } from "./RopHandler.js";
+export { isPlainEmailAddress, parseAddressList } from "./AddressList.js";
 /**
  * `RopSubmitMessage` (`[MS-OXOMSG]`/`[MS-OXCROPS]`): sends a composed message - the actual trigger point for
  * this pragmatic subset's compose/send pipeline, since `RopSaveChangesMessage` itself does no real persistence
@@ -22,12 +18,12 @@ export declare function parseAddressList(value: string | undefined): string[];
  * pragmatic subset's ROP coverage doesn't include. Instead, addressing is read from `PidTagDisplayTo`/
  * `DisplayCc`/`DisplayBcc` - the same semicolon-separated "cached recipient display string" properties real
  * Outlook *also* always sets via `RopSetProperties` alongside `RopModifyRecipients` (as a display-only
- * convenience cache). This works correctly for the common case of composing to bare, unresolved email
- * addresses (nothing to resolve to a distinct display name) - the case this library's own integration tests
- * exercise - but is **not** a substitute for real recipient rows: a client that resolves typed names against an
- * address book before submitting would populate these fields with display names, not addresses, and this
- * pragmatic subset has no way to recover a real SMTP address from a bare display name. Documented here rather
- * than silently producing wrong addressing.
+ * convenience cache). Entries are separated by `;` and parsed with nodemailer's `addressparser`, so both bare
+ * addresses and resolved `Name <address>` forms work. A client that resolved a name against an address book may
+ * write the display name alone; that is looked up among the caller's own contacts (see `resolveRecipientList`), and
+ * a name matching no single contact fails the submit with `MAPI_E_NOT_FOUND`. It is still **not** a substitute for
+ * real recipient rows (there is no recipient table to fall back on), so the whole send is refused rather than sent to
+ * fewer people than the user addressed. A malformed recipient fails with `MAPI_E_INVALID_PARAMETER`.
  *
  * `SubmitFlags` (`PreprocessOnly`, ...) is decoded to advance past it correctly but not honored - this
  * pragmatic subset has no transport-agent preprocessing distinction to vary by flag.
@@ -40,6 +36,12 @@ export declare function parseAddressList(value: string | undefined): string[];
  * own `requestReceipt` field - honored only when the client explicitly sets it, not this mailbox's
  * `alwaysRequestReceiptInternal`/`External` defaults (those apply to the REST/webmail compose path only).
  *
+ * **Once per draft.** A mail or meeting-response draft is marked `submitted` as soon as a submit gets past the handle
+ * check, whatever the outcome, and a submitted draft can't be submitted again (`MAPI_E_INVALID_OBJECT`) or changed by
+ * `RopSetProperties`/`RopWriteStream`; its write-stream chunks are deleted once read. Each `Execute` runs at most
+ * `MAX_SUBMITS_PER_EXECUTE` submits, and a message may have at most `MAX_RECIPIENTS_PER_MESSAGE` recipients
+ * (`MAPI_E_TOO_BIG`), counted before any display name is looked up.
+ *
  * **Calendar branches**: a draft whose `PidTagMessageClass` starts with `"IPM.Appointment"` is routed to
  * `submitAppointment()` instead of the mail path below - see that method's own doc comment. One starting with
  * `"IPM.Schedule.Meeting.Resp."` (an attendee's own accept/decline/tentative response to a meeting this server
@@ -52,19 +54,27 @@ export declare class RopSubmitMessageHandler implements RopHandler {
     readonly ropId = 50;
     handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
     /**
-     * Submits a Calendar item. The appointment itself is already persisted (`RopSaveChangesMessageHandler`
-     * writes the real `CalendarEvent` row at Save time, unlike a mail draft, which stays purely in-session until
-     * Submit) - this method's only job is notifying attendees, if any were set (via `PidTagDisplayTo`/`Cc`,
-     * decoded into `CalendarEvent.attendees` at Save time). No attendees means no invite to send (e.g. a private,
-     * non-meeting appointment) - a well-formed success response either way, since the appointment already exists.
+     * Submits a Calendar item. The appointment itself is already persisted (`RopSaveChangesMessageHandler` writes the
+     * real `CalendarEvent` row at Save time, unlike a mail draft, which stays purely in-session until Submit), so there
+     * is nothing left to store and nothing is sent from here.
      *
-     * Unlike ordinary mail, there is no separate "Sent Items copy" to create - the appointment's durable copy
-     * *is* the `CalendarEvent` row already sitting in the organizer's own Calendar folder.
+     * **Invites are restapi's `MeetingSchedulingJob`'s job.** That job sends an iTIP `REQUEST` for every
+     * organizer-owned event whose `inviteSequenceSent` differs from its `sequence`, claiming each revision with a
+     * versioned update before sending and building the invite with restapi's own `buildEventIcs` (so a recurring
+     * meeting's invite carries its `RRULE` and exceptions). Saving stamps `inviteSequenceSent = sequence`, so a meeting
+     * that is only saved ("Save & Close", or "save changes but don't send") invites no one. Submitting clears the stamp
+     * (`inviteSequenceSent: null`) with a versioned update, which makes the job send the current revision exactly once.
+     * - A revision that is already waiting for the job (submitted and not yet sent, or never stamped) is left alone, so
+     * submitting it again before the job runs doesn't cause a second invite.
+     * - The update is versioned (`asEntity`). The job only ever claims a waiting revision, so a conflict here comes from
+     * some other edit (an attendee's reply updating the row, a REST edit); the row is read again and the check repeated,
+     * up to `MAX_INVITE_REQUEST_ATTEMPTS` times, after which the ROP fails (`MAPI_E_CALL_FAILED`).
+     * - Submitting a revision the job has already sent sends it again: the client asked to send.
      *
-     * The invite itself is a minimal iCalendar (`RFC 5545`) `VEVENT` with `METHOD:REQUEST` (`RFC 5546`),
-     * attached via `nodemailer`'s own `MailComposer` `icalEvent` option (which produces both a `text/calendar;
-     * method=REQUEST` MIME alternative and an `.ics` attachment - the standard dual form real invite emails use)
-     * - reusing the identical `scanAndRelay()` pipeline the mail path above already calls.
+     * Only the organizer's own copy may be submitted (an attendee's copy of someone else's meeting answers
+     * `MAPI_E_INVALID_OBJECT`, as before, and nothing is changed).
      */
     private submitAppointment;
 }
+/** How many times `requestInvites` re-reads a row whose versioned update lost to another edit before giving up. */
+export declare const MAX_INVITE_REQUEST_ATTEMPTS = 3;

package/dist/types/rop/RopWriteStreamHandler.d.ts

@@ -1,14 +1,20 @@
 import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
-import type { RopContext, RopHandler } from "./RopHandler.js";
+import type { MapiObjectHandle } from "../MapiSessionManager.js";
+import { type RopContext, type RopHandler } from "./RopHandler.js";
+/** The largest body a write stream accumulates. */
+export declare const MAX_WRITE_STREAM_BYTES: number;
+/** How long a write stream's chunks are kept after its last write - the session's own idle lifetime. */
+export declare const WRITE_STREAM_TTL_SECONDS: number;
+export { writeStreamKey } from "./HandleDataCache.js";
 /**
  * `RopWriteStream` (`[MS-OXCPRPT]`/`[MS-OXCROPS]`): writes bytes to a stream opened in `ReadWrite`/`Create`
  * mode (`RopOpenStreamHandler`'s write-mode branch - the only kind of writable stream this pragmatic subset
- * ever produces, always a `RopCreateMessage` draft's `PidTagBody`). Accumulates `Data` into the stream handle's
- * `writeBufferBase64` field, decode-concat-reencode each call rather than a naive string concatenation of
- * per-call base64 chunks - base64 is not concatenation-safe (a chunk's padding only belongs at the true end of
- * the data), so reassembling the real bytes requires decoding what's accumulated so far, appending the new raw
- * bytes, and re-encoding the whole thing. `RopSaveChangesMessageHandler`/`RopSubmitMessageHandler` decode this
- * buffer back to the final body text once composing is complete.
+ * ever produces, always a `RopCreateMessage` draft's `PidTagBody`). Each write is stored as a chunk keyed by its
+ * offset in the `HandleDataStore` (Redis when configured), not in the session: only `writeSize` is session state.
+ * Keying by offset makes a retried write (after a request whose session save lost a conflict) replace its chunk
+ * instead of appending it twice. Up to `MAX_WRITE_STREAM_BYTES`; a write past that fails with `MAPI_E_TOO_BIG` and
+ * nothing is stored, as it is when the session's or user's handle data quota (`handleDataOwners`) is used up. A stream
+ * whose draft has already been submitted takes no more writes. `RopSubmitMessageHandler` reassembles the body (`readWriteStream`) once composing is complete.
  *
  * Like `RopReadStream`, `[MS-OXCROPS]` documents only one combined response-buffer shape for this ROP (no
  * separate Success/Failure pages) - `WrittenSize` is always present, `0` standing in for the failure case.
@@ -17,5 +23,9 @@ import type { RopContext, RopHandler } from "./RopHandler.js";
  */
 export declare class RopWriteStreamHandler implements RopHandler {
     readonly ropId = 45;
-    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
+    readonly failureTailBytes = 2;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
 }
+/** The bytes written so far to the write stream `stream` at `handleIndex`, or `undefined` when they can no longer be
+ * reassembled (a chunk expired or was evicted). */
+export declare function readWriteStream(context: RopContext, handleIndex: number, stream: MapiObjectHandle): Promise<Buffer | undefined>;

package/dist/types/rop/TaskTarget.d.ts

@@ -1,4 +1,5 @@
 import type { RepoUtils } from "@rapidrest/service-core";
+import type { RepoSort } from "./RepoPaging.js";
 /**
  * The `RopGetContentsTable`/`RopOpenMessage` analog of `MessageTarget.ts`, for a `Folder` of type `TASKS`:
  * resolves a `"task:<uid>"` row/handle target into the display data a task-item row or an opened task's
@@ -19,6 +20,5 @@ export interface TaskTargetInfo {
  * (soft-deleted or otherwise) - the same "don't fail the whole ROP over one stale row" principle
  * `MessageTarget.resolveMessageInfo`/`ContactTarget.resolveContactInfo` already apply. */
 export declare function resolveTaskInfo(target: string, taskRepo: RepoUtils<any>): Promise<TaskTargetInfo>;
-/** Resolves the tasks directly in `folderUid`, as `"task:<uid>"` target strings, for `RopGetContentsTable`
- * against a `TASKS`-type folder. */
-export declare function resolveFolderTasks(folderUid: string, taskRepo: RepoUtils<any>): Promise<string[]>;
+/** The order a `TASKS` folder's contents table lists tasks in (see `ContentsTable.ts`). */
+export declare const TASK_SORT: RepoSort;

package/dist/types/rop/TransportSend.d.ts

@@ -0,0 +1,10 @@
+import type { MailTransport, OutboundMessage, TransportResult } from "@rapidmx/restapi";
+/**
+ * Sends `message` and throws unless the transport accepted it for at least one recipient and rejected none.
+ *
+ * The same rule as restapi's own `sendOrThrow()` (`transport/TransportResultUtils.ts`), which isn't exported from
+ * the `@rapidmx/restapi` package root, so it can't be imported here; keep the two in sync. Every bundled transport
+ * reports a failed relay through `TransportResult.rejected` rather than throwing, so a bare `send()` would treat a
+ * rejected message as sent.
+ */
+export declare function sendOrThrow(transport: MailTransport, message: OutboundMessage): Promise<TransportResult>;

package/dist/types/sql/MapiEmsmdbRouteSQL.d.ts

@@ -15,5 +15,6 @@ export declare class MapiEmsmdbRouteSQL extends BaseMapiEmsmdbRoute<MailboxSQL>
     protected contactClass: any;
     protected taskClass: any;
     protected labelClass: any;
+    protected auditLogClass: any;
     protected ropHandlerClasses: any[];
 }

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@rapidmx/mapi-plugin",
-    "version": "1.0.0-beta.3",
+    "version": "1.0.0-beta.5",
     "description": "A RapidMX plugin that provides MAPI over HTTP protocol support.",
     "repository": "https://github.com/RapidMX/mapi.git",
     "author": "RapidREST <rapidrests@gmail.com>",
@@ -31,9 +31,9 @@
         "nodemailer": "^10.0.1"
     },
     "devDependencies": {
-        "@rapidmx/restapi": "^0.9.0",
+        "@rapidmx/restapi": "^0.17.0",
         "@rapidrest/core": "^5.2.2",
-        "@rapidrest/service-core": "^2.0.0",
+        "@rapidrest/service-core": "^2.1.0",
         "@swc/core": "^1.16.2",
         "@types/mailparser": "^3.4.6",
         "@types/nconf": "^0.10.7",