Internet Message Access Protocol (IMAP) - UIDPLUS extension
obsoletes
- rfc-2359 — IMAP4 UIDPLUS extension
Extracted elements (18)
RFC 2359 implied a server must always return COPYUID/APPENDUID data, suggesting arbitrary data should be returned when persistent UIDs are unsupported. RFC 4315 adds UIDNOTSTICKY to explicitly signal non-persistent UID stores and exempts such mailboxes from returning COPYUID/APPENDUID.
UIDPLUS features are optimizations for disconnected-use clients; clients can provide equivalent functionality less efficiently using base IMAP protocol facilities. UID EXPUNGE specifically prevents inadvertent removal of messages marked \Deleted by other clients during disconnected periods.
If the server does not support UIDPLUS, the client should fall back to using STORE to temporarily remove \Deleted flags from messages it does not want expunged, issue EXPUNGE, then restore \Deleted flags; alternatively it may simply use EXPUNGE and risk unintended message removal.
For mailboxes with UIDNOTSTICKY status, the server MAY omit the APPENDUID or COPYUID response code as it is not meaningful.
In the case of a mailbox where the client can COPY or APPEND but not SELECT or EXAMINE, the server SHOULD NOT send an APPENDUID or COPYUID response code as it would disclose information about the mailbox.
Server implementations that advertise the UIDPLUS extension SHOULD return the APPENDUID and COPYUID response codes, with limited exceptions for mailboxes where SELECT/EXAMINE permission is not granted.
Servers SHOULD NOT have any UIDNOTSTICKY mail stores; this facility exists only to support legacy mail stores where persistent UIDs are technically infeasible.
The UID set form of the APPENDUID response code MUST NOT be used if only a single message was appended; in particular, a server MUST NOT send a range such as 123:123.
UIDs are assigned in strictly ascending order in the mailbox per IMAP section 2.3.1.1; UID sets may not contain extraneous UIDs or the symbol "*".
The APPENDUID response code is followed by the UIDVALIDITY of the destination mailbox and the UID assigned to the appended message, indicating the message was appended with that UID. When used with MULTIAPPEND for multiple messages, the second value is a UID set.
The COPYUID response code is followed by the UIDVALIDITY of the destination mailbox, a UID set of source message UIDs, and a corresponding UID set of destination UIDs assigned to the copied messages, in the same order.
The UID EXPUNGE command permanently removes all messages that both have the \Deleted flag set and have a UID included in the specified sequence set from the currently selected mailbox. Messages without \Deleted or with UIDs not in the set are unaffected.
The UIDNOTSTICKY response code indicates the selected mailbox is supported by a mail store that does not support persistent UIDs; UIDVALIDITY will differ each time the mailbox is selected. Returned in an untagged NO response to SELECT.
This document registers the UIDPLUS capability in the imap4-capabilities registry, replacing RFC 2359.
The COPYUID and APPENDUID response codes return information about the mailbox that may be sensitive if the mailbox has permissions permitting COPY or APPEND but not SELECT or EXAMINE. Consequently these response codes SHOULD NOT be issued if the client lacks SELECT/EXAMINE access.
A uid-set is defined as (uniqueid / uid-range) *("," uid-set), and a uid-range is two uniqueid values separated by ":" representing all values between them inclusive; e.g., 2:4 and 4:2 are equivalent.
The APPENDUID response code syntax is: "APPENDUID" SP nz-number SP append-uid, where append-uid is a uniqueid (or uid-set if MULTIAPPEND is used). The COPYUID response code syntax is: "COPYUID" SP nz-number SP uid-set SP uid-set.
The uid-expunge command syntax is: "UID" SP "EXPUNGE" SP sequence-set, extending the IMAP command-select rule.