@remit/api-openapi-types 0.0.30 → 0.0.32

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/api-openapi-types",
-  "version": "0.0.30",
+  "version": "0.0.32",
   "type": "module",
   "main": "types.d.ts",
   "types": "types.d.ts",

package/types.d.ts

@@ -142,9 +142,9 @@ current enum emitter anyway, so the wire contract uses the bare form.
      */
     export type SenderTrust = "unknown" | "wellknown" | "vip";
     /**
-     * How the From display name relates to the From domain. `Corresponds` — the name is contained in the domain. `Lookalike` — the name is one or two characters away from a domain label. `Unrelated` — no relation. `NoClaim` — the name is empty or is the address itself, so it claims no identity.
+     * How the From display name relates to the From domain. `Corresponds` — the name is contained in the domain. `Lookalike` — the name is one or two characters away from a domain label. `ForeignAddress` — the name spells out an email address at a domain the sender does not send from. `Unrelated` — no relation. `NoClaim` — the name is empty, or is an address at the sending domain, so it claims no other identity.
      */
-    export type DisplayNameCorrespondence = "Corresponds" | "Lookalike" | "Unrelated" | "NoClaim";
+    export type DisplayNameCorrespondence = "Corresponds" | "Lookalike" | "ForeignAddress" | "Unrelated" | "NoClaim";
     /**
      * Actionable placement verdict — the direction Remit decided to move a message. `leave` is not represented: a left-in-place verdict means the placement sub-model is absent.
      */
@@ -2762,6 +2762,25 @@ present only when `count=true`. Thread-specific so the shared `ResultList<T>`
        * SMTP server's Message-ID response (if different)
        */
       smtpMessageId?: string;
+      /**
+       * Whether the IMAP APPEND that files a copy in Sent has been confirmed, and
+the uid it produced. Written between the APPEND and the row delete that
+follows it, so a redelivered APPEND event skips straight to the delete
+instead of filing a second copy of the same message.
+
+Three readings, no absent one: the named sentinel `0` means no APPEND has
+been confirmed for this row. The named sentinel `-1` means an APPEND was
+confirmed but the server named no uid for it — UIDPLUS is an extension, and
+a server without it files the copy and reports nothing. Any positive value
+is the uid the server assigned. Only the latter two mean the copy exists, so
+a value neither of them reads as unfiled, which re-files at worst rather
+than dropping the row of a message that reached no folder.
+
+Deliberately not paired with a uidValidity: this never addresses the
+message, it only records that the copy exists. Everything that names a
+message forever (Message, Quarantine) stores both.
+       */
+      appendedUid: number;
       createdAt: number;
       updatedAt: number;
     }