📄 rfc5162.txt
字号:
S: ... S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ (90060115194045001)) S: A03 OK [READ-WRITE] mailbox selected Message sequence match data: A client MAY provide a parenthesized list of a message sequence set and the corresponding UID sets. Both MUST be provided in ascending order. The server uses this data to restrict the range for which it provides expunged message information.Melnikov, et al. Standards Track [Page 6] RFC 5162 IMAP Quick Mailbox Resync March 2008 Conceptually, the client provides a small sample of sequence numbers for which it knows the corresponding UIDs. The server then compares each sequence number and UID pair the client provides with the current state of the mailbox. If a pair matches, then the client knows of any expunges up to, and including, the message, and thus will not include that range in the VANISHED response, even if the "mod-sequence-value" provided by the client is too old for the server to have data of when those messages were expunged. Thus, if the Nth message number in the first set in the list is 4, and the Nth UID in the second set in the list is 8, and the mailbox's fourth message has UID 8, then no UIDs equal to or less than 8 are present in the VANISHED response. If the (N+1)th message number is 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox has UID 25, then the lowest UID included in the VANISHED response would be 9. In the following two examples, the server is unable to remember expunges at all, and only UIDs with messages divisible by three are present in the mailbox. In the first example, the client does not use the fourth parameter; in the second, it provides it. This example is somewhat extreme, but shows that judicious usage of the sequence match data can save a substantial amount of bandwidth. Example: C: A04 SELECT INBOX (QRESYNC (67890007 90060115194045000 1:29997)) S: * 10003 EXISTS S: * 5 RECENT S: * OK [UIDVALIDITY 67890007] UIDVALIDITY S: * OK [UIDNEXT 30013] Predicted next UID S: * OK [HIGHESTMODSEQ 90060115205545359] S: * OK [UNSEEN 7] There are some unseen messages in the mailbox S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Permanent flags S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...] 29998:29999,30001:30002,30004:30005,30007:30008 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ (90060115194045027)) S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ (90060115194045028)) S: ... S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ (90060115194045031)) S: A04 OK [READ-WRITE] mailbox selectedMelnikov, et al. Standards Track [Page 7] RFC 5162 IMAP Quick Mailbox Resync March 2008 Example: C: B04 SELECT INBOX (QRESYNC (67890007 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000, 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991, 29994,29997))) S: * 10003 EXISTS S: * 5 RECENT S: * OK [UIDVALIDITY 67890007] UIDVALIDITY S: * OK [UIDNEXT 30013] Predicted next UID S: * OK [HIGHESTMODSEQ 90060115205545359] S: * OK [UNSEEN 7] There are some unseen messages in the mailbox S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Permanent flags S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007: 30008 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ (90060115194045027)) S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ (90060115194045028)) S: ... S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ (90060115194045031)) S: B04 OK [READ-WRITE] mailbox selected3.2. VANISHED UID FETCH Modifier [IMAPABNF] has extended the syntax of the FETCH and UID FETCH commands to include an optional FETCH modifier. This document defines a new UID FETCH modifier: VANISHED. Note, that the VANISHED UID FETCH modifier is NOT allowed with a FETCH command. The server MUST return a tagged BAD response if this response is specified as a modifier to the FETCH command. A server MUST respond with a tagged BAD response if the VANISHED UID FETCH modifier is specified and the client hasn't issued "ENABLE QRESYNC" in the current connection. The VANISHED UID FETCH modifier MUST only be specified together with the CHANGEDSINCE UID FETCH modifier. The VANISHED UID FETCH modifier instructs the server to report those messages from the UID set parameter that have been expunged and whose associated mod-sequence is larger than the specified mod-sequence. That is, the client requests to be informed of messages from the specified set that were expunged since the specified mod-sequence. Note that the mod-sequence(s) associated with these messages wereMelnikov, et al. Standards Track [Page 8] RFC 5162 IMAP Quick Mailbox Resync March 2008 updated when the messages were expunged (as described above). The expunged messages are reported using the VANISHED response as described in Section 3.6, which MUST contain the EARLIER tag. Any VANISHED (EARLIER) responses MUST be returned before any FETCH responses, as otherwise the client might get confused about how message numbers map to UIDs. Note: A server that receives a mod-sequence smaller than <minmodseq>, where <minmodseq> is the value of the smallest expunged mod-sequence it remembers minus one, MUST behave as if it was requested to report all expunged messages from the provided UID set parameter. Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware client [CONDSTORE] needs to issue separate commands to learn of flag changes and expunged messages since the last synchronization: C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345) S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent)) S: s100 OK FETCH completed C: s101 UID SEARCH 300:500 S: * SEARCH 404 406 407 408 410 412 S: s101 OK search completed Where 300 and 500 are the lowest and highest UIDs from client's cache. The second SEARCH response tells the client that the messages with UIDs 407, 410, and 412 are still present, but their flags haven't changed since the specified modification sequence. Using the VANISHED UID FETCH modifier, it is sufficient to issue only a single command: C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345 VANISHED) S: * VANISHED (EARLIER) 300:310,405,411 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk $MDNSent)) S: s100 OK FETCH completedMelnikov, et al. Standards Track [Page 9] RFC 5162 IMAP Quick Mailbox Resync March 20083.3. EXPUNGE Command Arguments: none Responses: untagged responses: EXPUNGE or VANISHED Result: OK - expunge completed NO - expunge failure: can't expunge (e.g., permission denied) BAD - command unknown or arguments invalid This section updates the definition of the EXPUNGE command described in Section 6.4.3 of [RFC3501]. The EXPUNGE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox. Before returning an OK to the client, those messages that are removed are reported using a VANISHED response or EXPUNGE responses. If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the EXPUNGE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response. Example: C: A202 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 5 EXPUNGE S: * 8 EXPUNGE S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE" reports message # 4 as expunged (the message number got decremented due to the previous EXPUNGE response). See the description of the EXPUNGE response in [RFC3501] for further explanation. Note that if the server chooses to always send VANISHED responses instead of EXPUNGE responses, the previous example might look like this: Example: C: B202 EXPUNGE S: * VANISHED 405,407,410,425 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expungedMelnikov, et al. Standards Track [Page 10] RFC 5162 IMAP Quick Mailbox Resync March 2008 Here messages with message numbers 3, 4, 7, and 11 have respective UIDs 405, 407, 410, and 425.3.4. CLOSE Command Arguments: none Responses: no specific responses for this command Result: OK - close completed, now in authenticated state BAD - command unknown or arguments invalid This section updates the definition of the CLOSE command described in Section 6.4.2 of [RFC3501]. The CLOSE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox, and returns to the authenticated state from the selected state. No untagged EXPUNGE (or VANISHED) responses are sent. If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the CLOSE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response. Example: C: A202 CLOSE S: A202 OK [HIGHESTMODSEQ 20010715194045319] done3.5. UID EXPUNGE Command Arguments: message set Responses: untagged responses: EXPUNGE or VANISHED Result: OK - expunge completed NO - expunge failure: can't expunge (e.g., permission denied) BAD - command unknown or arguments invalid This section updates the definition of the UID EXPUNGE command described in Section 2.1 of [UIDPLUS]. Servers that implement both [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as described in this section.Melnikov, et al. Standards Track [Page 11] RFC 5162 IMAP Quick Mailbox Resync March 2008 The UID EXPUNGE command permanently removes from the currently selected mailbox all messages that both have the \Deleted flag set and have a UID that is included in the specified message set. If a message either does not have the \Deleted flag set or has a UID that is not included in the specified message set, it is not affected. This command is particularly useful for disconnected mode clients. By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the server, the client can avoid inadvertently removing any messages that have been marked as \Deleted by other clients between the time that the client was last connected and the time the client resynchronizes. Before returning an OK to the client, those messages that are removed are reported using a VANISHED response or EXPUNGE responses. If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the UID EXPUNGE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -