@remit/api-openapi-types 0.0.31 → 0.0.32
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/types.d.ts +19 -0
package/package.json
CHANGED
package/types.d.ts
CHANGED
|
@@ -2762,6 +2762,25 @@ present only when `count=true`. Thread-specific so the shared `ResultList<T>`
|
|
|
2762
2762
|
* SMTP server's Message-ID response (if different)
|
|
2763
2763
|
*/
|
|
2764
2764
|
smtpMessageId?: string;
|
|
2765
|
+
/**
|
|
2766
|
+
* Whether the IMAP APPEND that files a copy in Sent has been confirmed, and
|
|
2767
|
+
the uid it produced. Written between the APPEND and the row delete that
|
|
2768
|
+
follows it, so a redelivered APPEND event skips straight to the delete
|
|
2769
|
+
instead of filing a second copy of the same message.
|
|
2770
|
+
|
|
2771
|
+
Three readings, no absent one: the named sentinel `0` means no APPEND has
|
|
2772
|
+
been confirmed for this row. The named sentinel `-1` means an APPEND was
|
|
2773
|
+
confirmed but the server named no uid for it — UIDPLUS is an extension, and
|
|
2774
|
+
a server without it files the copy and reports nothing. Any positive value
|
|
2775
|
+
is the uid the server assigned. Only the latter two mean the copy exists, so
|
|
2776
|
+
a value neither of them reads as unfiled, which re-files at worst rather
|
|
2777
|
+
than dropping the row of a message that reached no folder.
|
|
2778
|
+
|
|
2779
|
+
Deliberately not paired with a uidValidity: this never addresses the
|
|
2780
|
+
message, it only records that the copy exists. Everything that names a
|
|
2781
|
+
message forever (Message, Quarantine) stores both.
|
|
2782
|
+
*/
|
|
2783
|
+
appendedUid: number;
|
|
2765
2784
|
createdAt: number;
|
|
2766
2785
|
updatedAt: number;
|
|
2767
2786
|
}
|