Internet Engineering Task Force (IETF) B. Gondwana, Ed.
Request for Comments: 8474 FastMail
Updates: 3501 September 2018
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) B. Gondwana, Ed.
Request for Comments: 8474 FastMail
Updates: 3501 September 2018
Category: Standards Track
ISSN: 2070-1721
IMAP Extension for Object Identifiers
对象标识符的IMAP扩展
Abstract
摘要
This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server.
本文档使用邮箱和消息上的持久标识符更新RFC 3501（IMAP4rev1），以便在资源在服务器上的位置发生更改时，客户端能够更高效地重用缓存的数据。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8474.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8474.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. CAPABILITY Identification . . . . . . . . . . . . . . . . . . 3
4. MAILBOXID Object Identifier . . . . . . . . . . . . . . . . . 3
4.1. New Response Code for CREATE . . . . . . . . . . . . . . 4
4.2. New OK Untagged Response for SELECT and EXAMINE . . . . . 4
4.3. New Attribute for STATUS . . . . . . . . . . . . . . . . 5
5. EMAILID Object Identifier and THREADID Correlator . . . . . . 6
5.1. EMAILID Identifier for Identical Messages . . . . . . . . 6
5.2. THREADID Identifier for Related Messages . . . . . . . . 6
5.3. New Message Data Items in FETCH and UID FETCH Commands . 7
6. New Filters on SEARCH Command . . . . . . . . . . . . . . . . 9
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Implementation Considerations . . . . . . . . . . . . . . . . 10
8.1. Assigning Object Identifiers . . . . . . . . . . . . . . 10
8.2. Interaction with Special Cases . . . . . . . . . . . . . 11
8.3. Client Usage . . . . . . . . . . . . . . . . . . . . . . 11
8.4. Advice to Client Implementers . . . . . . . . . . . . . . 12
9. Future Considerations . . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Ideas for Implementing Object Identifiers . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. CAPABILITY Identification . . . . . . . . . . . . . . . . . . 3
4. MAILBOXID Object Identifier . . . . . . . . . . . . . . . . . 3
4.1. New Response Code for CREATE . . . . . . . . . . . . . . 4
4.2. New OK Untagged Response for SELECT and EXAMINE . . . . . 4
4.3. New Attribute for STATUS . . . . . . . . . . . . . . . . 5
5. EMAILID Object Identifier and THREADID Correlator . . . . . . 6
5.1. EMAILID Identifier for Identical Messages . . . . . . . . 6
5.2. THREADID Identifier for Related Messages . . . . . . . . 6
5.3. New Message Data Items in FETCH and UID FETCH Commands . 7
6. New Filters on SEARCH Command . . . . . . . . . . . . . . . . 9
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Implementation Considerations . . . . . . . . . . . . . . . . 10
8.1. Assigning Object Identifiers . . . . . . . . . . . . . . 10
8.2. Interaction with Special Cases . . . . . . . . . . . . . 11
8.3. Client Usage . . . . . . . . . . . . . . . . . . . . . . 11
8.4. Advice to Client Implementers . . . . . . . . . . . . . . 12
9. Future Considerations . . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Ideas for Implementing Object Identifiers . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
IMAP stores are often used by many clients. Each client may cache data from the server so that it doesn't need to redownload information. [RFC3501] states that a mailbox can be uniquely referenced by its name and UIDVALIDITY, and a message within that mailbox can be uniquely referenced by its mailbox (name + UIDVALIDITY) and unique identifier (UID). The triple of mailbox name, UIDVALIDITY, and UID is guaranteed to be immutable.
IMAP存储通常被许多客户机使用。每个客户端都可以缓存来自服务器的数据，这样就不需要重新下载信息。[RFC3501]声明邮箱可以通过其名称和UID有效性进行唯一引用，邮箱中的邮件可以通过其邮箱（名称+UID有效性）和唯一标识符（UID）进行唯一引用。邮箱名称、UIDValicity和UID的三元组保证是不可变的。
[RFC4315] defines a COPYUID response that allows a client that copies messages to know the mapping between the UIDs in the source and destination mailboxes and, hence, update its local cache.
[RFC4315]定义COPYUID响应，该响应允许复制消息的客户端知道源邮箱和目标邮箱中UID之间的映射，从而更新其本地缓存。
If a mailbox is successfully renamed by a client, that client will know that the same messages exist in the destination mailbox name as previously existed in the source mailbox name.
如果客户端成功重命名邮箱，则该客户端将知道目标邮箱名称中存在的邮件与源邮箱名称中以前存在的邮件相同。
The result is that the client that copies (or moves [RFC6851]) messages or renames a mailbox can update its local cache, but any other client connected to the same store cannot know with certainty that the messages are identical, so it will redownload everything.
结果是，复制（或移动[RFC6851]）邮件或重命名邮箱的客户端可以更新其本地缓存，但连接到同一存储的任何其他客户端都无法确定邮件是否相同，因此将重新下载所有内容。
This extension adds new properties to a message (EMAILID) and mailbox (MAILBOXID). These properties allow a client to quickly identify messages or mailboxes that have been renamed by another client.
此扩展向邮件（EMAILID）和邮箱（MAILBOXID）添加新属性。这些属性允许客户端快速识别已被其他客户端重命名的邮件或邮箱。
This extension also adds an optional thread identifier (THREADID) to messages, which can be used by the server to indicate messages that it has identified to be related. A server that does not implement threading will return NIL to all requests for THREADID.
此扩展还向消息中添加了可选的线程标识符（THREADID），服务器可以使用该标识符指示已标识为相关的消息。未实现线程化的服务器将对THREADID的所有请求返回NIL。
In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.
在示例中，“C:”表示连接到服务器的客户端发送的线路。“S:”表示服务器发送到客户端的行。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
IMAP servers that support this extension MUST include "OBJECTID" in the response list to the CAPABILITY command.
支持此扩展的IMAP服务器必须在CAPABILITY命令的响应列表中包含“OBJECTID”。
The MAILBOXID is a server-allocated unique identifier for each mailbox.
MAILBOXID是服务器为每个邮箱分配的唯一标识符。
The server MUST return the same MAILBOXID for a mailbox with the same name and UIDVALIDITY.
对于具有相同名称和UID有效性的邮箱，服务器必须返回相同的MAILBOXID。
The server MUST NOT report the same MAILBOXID for two mailboxes at the same time.
服务器不能同时报告两个邮箱的相同MAILBOXID。
The server MUST NOT reuse the same MAILBOXID for a mailbox that does not obey all the invariants that [RFC3501] defines for a mailbox that does not change name or UIDVALIDITY.
对于不遵守[RFC3501]为不更改名称或UIDVality的邮箱定义的所有不变量的邮箱，服务器不得重复使用相同的邮箱ID。
The server MUST keep the same MAILBOXID for the source and destination when renaming a mailbox in a way that keeps the same messages (but see [RFC3501] for the special case regarding the renaming of INBOX, which is treated as creating a new mailbox and moving the messages).
当以保留相同邮件的方式重命名邮箱时，服务器必须为源和目标保留相同的邮箱ID（但有关重命名收件箱的特殊情况，请参见[RFC3501]，这被视为创建新邮箱和移动邮件）。
This document extends the CREATE command to have the response code MAILBOXID on successful mailbox creation.
此文档扩展了CREATE命令，使其在成功创建邮箱时具有响应代码MAILBOXID。
A server advertising the OBJECTID capability MUST include the MAILBOXID response code in the tagged OK response to all successful CREATE commands.
发布OBJECTID功能的服务器必须在对所有成功创建命令的标记好响应中包含MAILBOXID响应代码。
Syntax: "MAILBOXID" SP "(" objectid ")"
语法：“MAILBOXID”SP”（“objectid”）“
Response code in tagged OK response for successful CREATE command.
成功创建命令的标记好响应中的响应代码。
Example:
例子：
C: 3 create foo
S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Completed
C: 4 create bar
S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)] Completed
C: 5 create foo
S: 5 NO Mailbox already exists
C: 3 create foo
S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Completed
C: 4 create bar
S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)] Completed
C: 5 create foo
S: 5 NO Mailbox already exists
This document adds a new untagged response code to the SELECT and EXAMINE commands.
本文档向SELECT和EXAMINE命令添加新的未标记响应代码。
A server advertising the OBJECTID capability MUST return an untagged OK response with the MAILBOXID response code on all successful SELECT and EXAMINE commands.
公布OBJECTID功能的服务器必须在所有成功的SELECT和Inspect命令上返回带有MAILBOXID响应代码的未标记OK响应。
Syntax: "OK" SP "[" "MAILBOXID" SP "(" objectid ")" "]" SP text
语法：“OK”SP“[“MAILBOXID”SP”（“objectid”）“”]“SP text
Untagged OK response to SELECT or EXAMINE.
未标记的OK响应以选择或检查。
Example:
例子：
C: 27 select "foo"
[...]
S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Ok
[...]
S: 27 OK [READ-WRITE] Completed
C: 27 select "foo"
[...]
S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Ok
[...]
S: 27 OK [READ-WRITE] Completed
This document adds the MAILBOXID attribute to the STATUS command using the extended syntax defined in [RFC4466].
本文档使用[RFC4466]中定义的扩展语法将MAILBOXID属性添加到STATUS命令中。
A server that advertises the OBJECTID capability MUST support the MAILBOXID status attribute.
播发OBJECTID功能的服务器必须支持MAILBOXID状态属性。
Syntax: "MAILBOXID"
语法：“MAILBOXID”
The attribute in the STATUS command.
STATUS命令中的属性。
Syntax: "MAILBOXID" SP "(" objectid ")"
语法：“MAILBOXID”SP”（“objectid”）“
The response item in the STATUS response contains the ObjectID assigned by the server for this mailbox.
状态响应中的响应项包含服务器为此邮箱分配的ObjectID。
Example:
例子：
C: 6 status foo (mailboxid)
S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 6 OK Completed
C: 7 status bar (mailboxid)
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: 7 OK Completed
C: 8 rename foo renamed
S: * OK rename foo renamed
S: 8 OK Completed
C: 9 status renamed (mailboxid)
S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 9 OK Completed
C: 10 status bar (mailboxid)
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: 10 OK Completed
C: 6 status foo (mailboxid)
S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 6 OK Completed
C: 7 status bar (mailboxid)
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: 7 OK Completed
C: 8 rename foo renamed
S: * OK rename foo renamed
S: 8 OK Completed
C: 9 status renamed (mailboxid)
S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 9 OK Completed
C: 10 status bar (mailboxid)
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: 10 OK Completed
When the LIST-STATUS IMAP capability defined in [RFC5819] is also available, the STATUS command can be combined with the LIST command.
当[RFC5819]中定义的LIST-STATUS IMAP功能也可用时，STATUS命令可与LIST命令组合使用。
Example:
例子：
C: 11 list "" "*" return (status (mailboxid))
S: * LIST (\HasNoChildren) "." INBOX
S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf))
S: * LIST (\HasNoChildren) "." bar
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: * LIST (\HasNoChildren) "." renamed
S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 11 OK Completed (0.001 secs 3 calls)
C: 11 list "" "*" return (status (mailboxid))
S: * LIST (\HasNoChildren) "." INBOX
S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf))
S: * LIST (\HasNoChildren) "." bar
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: * LIST (\HasNoChildren) "." renamed
S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 11 OK Completed (0.001 secs 3 calls)
The EMAILID data item is an ObjectID that uniquely identifies the content of a single message. Anything that must remain immutable on a {name, uidvalidity, uid} triple must also be the same between messages with the same EMAILID.
EMAILID数据项是唯一标识单个邮件内容的ObjectID。任何必须在{name，uidvalidity，uid}三元组上保持不变的内容在具有相同EMAILID的邮件之间也必须相同。
The server MUST return the same EMAILID for the same triple; hence, EMAILID is immutable.
服务器必须为同一个三元组返回相同的EMAILID；因此，EMAILID是不可变的。
The server MUST return the same EMAILID as the source message for the matching destination message in the COPYUID pairing after a COPY or MOVE command [RFC6851].
在执行复制或移动命令[RFC6851]后，服务器必须返回与COPYUID配对中匹配的目标邮件的源邮件相同的EMAILID。
The server MAY assign the same EMAILID as an existing message upon APPEND (e.g., if it detects that the new message has exactly identical content to that of an existing message).
服务器可以在附加时将相同的EMAILID分配给现有邮件（例如，如果它检测到新邮件的内容与现有邮件的内容完全相同）。
NOTE: EMAILID only identifies the immutable content of the message. In particular, it is possible for different messages with the same EMAILID to have different keywords. This document does not specify a way to STORE by EMAILID.
注意：EMAILID仅标识邮件的不可变内容。特别是，具有相同EMAILID的不同邮件可能具有不同的关键字。此文档未指定按EMAILID存储的方式。
The THREADID data item is an ObjectID that uniquely identifies a set of messages that the server believes should be grouped together when presented.
THREADID数据项是一个ObjectID，它唯一地标识一组服务器认为应该在显示时分组在一起的消息。
THREADID calculation is generally based on some combination of References, In-Reply-To, and Subject, but the exact logic is left up to the server implementation. [RFC5256] describes some algorithms that could be used; however, this specification does not mandate any particular strategy.
THREADID计算通常基于引用、回复和主题的某些组合，但具体逻辑由服务器实现决定。[RFC5256]描述了一些可以使用的算法；然而，本规范并不要求任何特定的策略。
The server MUST return the same THREADID for all messages with the same EMAILID.
服务器必须为具有相同EMAILID的所有邮件返回相同的THREADID。
The server SHOULD return the same THREADID for related messages, even if they are in different mailboxes; for example, messages that would appear in the same thread if they were in the same mailbox SHOULD have the same THREADID, even if they are in different mailboxes.
服务器应为相关邮件返回相同的THREADID，即使它们位于不同的邮箱中；例如，如果邮件位于同一邮箱中，则会出现在同一线程中的邮件应该具有相同的THREADID，即使它们位于不同的邮箱中。
The server MUST NOT change the THREADID of a message once reported.
一旦报告，服务器不得更改邮件的THREADID。
THREADID is OPTIONAL; if the server doesn't support THREADID or is unable to calculate relationships between messages, it MUST return NIL to all FETCH responses for the THREADID data item, and a SEARCH for THREADID MUST NOT match any messages.
THREADID是可选的；如果服务器不支持THREADID或无法计算消息之间的关系，则必须为THREADID数据项的所有获取响应返回NIL，并且对THREADID的搜索不得与任何消息匹配。
The server MUST NOT use the same ObjectID value for both EMAILIDs and THREADIDs. If they are stored with the same value internally, the server can generate prefixed values (as shown in the examples below with M and T prefixes) to avoid clashes.
服务器不能对EmailID和ThreadID使用相同的ObjectID值。如果它们在内部以相同的值存储，服务器可以生成前缀值（如下面的示例所示，前缀为M和T），以避免冲突。
This document defines two FETCH items:
本文档定义了两个获取项：
Syntax: "EMAILID"
语法：“EMAILID”
The EMAILID message data item causes the server to return EMAILID FETCH response data items.
EMAILID消息数据项导致服务器返回EMAILID获取响应数据项。
Syntax: "THREADID"
语法：“THREADID”
The THREADID message data item causes the server to return THREADID FETCH response data items.
THREADID消息数据项导致服务器返回THREADID获取响应数据项。
This document defines the following responses:
本文件定义了以下响应：
Syntax: "EMAILID" SP "(" objectid ")"
语法：“EMAILID”SP”（“objectid”）“
The EMAILID response data item contains the server-assigned ObjectID for each message.
EMAILID响应数据项包含服务器为每封邮件分配的ObjectID。
Syntax: "THREADID" SP "(" objectid ")"
语法：“THREADID”SP”（“objectid”）“
The THREADID response data item contains the server-assigned ObjectID for the set of related messages to which this message belongs.
THREADID响应数据项包含服务器为该消息所属的相关消息集分配的ObjectID。
Syntax: "THREADID" SP nil
语法：“THREADID”SP nil
The NIL value is returned for the THREADID response data item when the server mailbox does not support THREADID calculation.
当服务器邮箱不支持THREADID计算时，将为THREADID响应数据项返回NIL值。
Example:
例子：
C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733}
[...]
Subject: Message A
Message-ID: <fake.1521475657.54797@example.com>
[...]
S: 5 OK [APPENDUID 1521475658 1] Completed
C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733}
[...]
Subject: Message A
Message-ID: <fake.1521475657.54797@example.com>
[...]
S: 5 OK [APPENDUID 1521475658 1] Completed
C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793}
[...]
Subject: Re: Message A
Message-ID: <fake.1521475657.21213@example.org>
References: <fake.1521475657.54797@example.com>
[...]
S: 11 OK [APPENDUID 1521475658 2] Completed
C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793}
[...]
Subject: Re: Message A
Message-ID: <fake.1521475657.21213@example.org>
References: <fake.1521475657.54797@example.com>
[...]
S: 11 OK [APPENDUID 1521475658 2] Completed
C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736}
[...]
Subject: Message C
Message-ID: <fake.1521475657.60280@example.com>
[...]
S: 17 OK [APPENDUID 1521475658 3] Completed
C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736}
[...]
Subject: Message C
Message-ID: <fake.1521475657.60280@example.com>
[...]
S: 17 OK [APPENDUID 1521475658 3] Completed
C: 22 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9))
S: * 2 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9))
S: * 3 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5))
S: 22 OK Completed (0.000 sec)
C: 22 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9))
S: * 2 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9))
S: * 3 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5))
S: 22 OK Completed (0.000 sec)
C: 23 move 2 foo
S: * OK [COPYUID 1521475659 2 1] Completed
S: * 2 EXPUNGE
S: 23 OK Completed
C: 23 move 2 foo
S: * OK [COPYUID 1521475659 2 1] Completed
S: * 2 EXPUNGE
S: 23 OK Completed
C: 24 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9))
S: * 2 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5))
S: 24 OK Completed (0.000 sec)
C: 25 select "foo"
C: 24 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9))
S: * 2 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5))
S: 24 OK Completed (0.000 sec)
C: 25 select "foo"
C: 25 select "foo"
[...]
S: 25 OK [READ-WRITE] Completed
C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9))
S: 26 OK Completed (0.000 sec)
C: 25 select "foo"
[...]
S: 25 OK [READ-WRITE] Completed
C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9))
S: 26 OK Completed (0.000 sec)
Example: (no THREADID support)
示例：（不支持THREADID）
C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M00000001) THREADID NIL)
S: * 2 FETCH (EMAILID (M00000002) THREADID NIL)
S: 26 OK Completed (0.000 sec)
C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M00000001) THREADID NIL)
S: * 2 FETCH (EMAILID (M00000002) THREADID NIL)
S: 26 OK Completed (0.000 sec)
This document defines the filters EMAILID and THREADID on the SEARCH command.
此文档定义搜索命令上的筛选器EMAILID和THREADID。
Syntax: "EMAILID" SP objectid
语法：“EMAILID”SP objectid
Messages whose EMAILID is exactly the specified ObjectID.
EMAILID与指定ObjectID完全相同的邮件。
Syntax: "THREADID" SP objectid
语法：“THREADID”SP objectid
Messages whose THREADID is exactly the specified ObjectID.
THREADID正好是指定ObjectID的消息。
Example: (as if run before the MOVE shown above when the mailbox had three messages)
示例：（当邮箱有三条消息时，就好像在上面显示的移动之前运行一样）
C: 27 search emailid M6d99ac3275bb4e
S: * SEARCH 1
S: 27 OK Completed (1 msgs in 0.000 secs)
C: 28 search threadid T64b478a75b7ea9
S: * SEARCH 1 2
S: 28 OK Completed (2 msgs in 0.000 secs)
C: 27 search emailid M6d99ac3275bb4e
S: * SEARCH 1
S: 27 OK Completed (1 msgs in 0.000 secs)
C: 28 search threadid T64b478a75b7ea9
S: * SEARCH 1 2
S: 28 OK Completed (2 msgs in 0.000 secs)
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation. Elements not defined here can be found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], and IMAP ABNF extensions [RFC4466] specifications.
以下语法规范使用增广的Backus-Naur形式（ABNF）[RFC5234]表示法。这里未定义的元素可以在ABNF[RFC5234]、IMAP[RFC3501]和IMAP ABNF扩展[RFC4466]规范的形式语法中找到。
Except as noted otherwise, all alphabetic characters are case insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅用于编辑清晰性。实现必须以不区分大小写的方式接受这些字符串。
Please note specifically that ObjectID values are case sensitive.
请特别注意ObjectID值区分大小写。
capability =/ "OBJECTID"
能力=/“OBJECTID”
fetch-att =/ "EMAILID" / "THREADID"
fetch-att =/ "EMAILID" / "THREADID"
fetch-emailid-resp = "EMAILID" SP "(" objectid ")" ; follows tagged-ext production from [RFC4466]
获取emailid resp=“emailid”SP”（“objectid”）；以下是[RFC4466]的带标记的外部生产
fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil )
; follows tagged-ext production from [RFC4466]
fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil )
; follows tagged-ext production from [RFC4466]
msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp
msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp
objectid = 1*255(ALPHA / DIGIT / "_" / "-")
; characters in object identifiers are case
; significant
objectid = 1*255(ALPHA / DIGIT / "_" / "-")
; characters in object identifiers are case
; significant
resp-text-code =/ "MAILBOXID" SP "(" objectid ")"
; incorporated before the expansion rule of
; atom [SP 1*<any TEXT-CHAR except "]">]
; that appears in [RFC3501]
resp-text-code =/ "MAILBOXID" SP "(" objectid ")"
; incorporated before the expansion rule of
; atom [SP 1*<any TEXT-CHAR except "]">]
; that appears in [RFC3501]
search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid
search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid
status-att =/ "MAILBOXID"
状态att=/“邮箱ID”
status-att-val =/ "MAILBOXID" SP "(" objectid ")"
; follows tagged-ext production from [RFC4466]
status-att-val =/ "MAILBOXID" SP "(" objectid ")"
; follows tagged-ext production from [RFC4466]
All ObjectID values are allocated by the server.
所有ObjectID值都由服务器分配。
In the interest of reducing the possibilities of encoding mistakes, ObjectIDs are restricted to a safe subset of possible byte values; in order to allow clients to allocate storage, they are restricted in length.
为了减少编码错误的可能性，objectid被限制为可能字节值的安全子集；为了允许客户端分配存储，它们的长度受到限制。
An ObjectID is a string of 1 to 255 characters from the following set of 64 codepoints: a-z, A-Z, 0-9, _, -. These characters are safe to use in almost any context (e.g., filesystems, URIs, IMAP atoms). These are the same characters defined as base64url in [RFC4648].
ObjectID是一个由以下64个代码点组成的1到255个字符组成的字符串：a-z、a-z、0-9、——。这些字符几乎可以在任何上下文中安全使用（例如，文件系统、URI、IMAP原子）。这些字符与[RFC4648]中定义为base64url的字符相同。
For maximum safety, servers should also follow defensive allocation strategies to avoid creating risks where glob completion or data type detection may be present (e.g., on filesystems or in spreadsheets). In particular, it is wise to avoid:
为了最大限度的安全，服务器还应遵循防御性分配策略，以避免在可能存在全局完成或数据类型检测的情况下（例如，在文件系统或电子表格中）产生风险。特别是，明智的做法是避免：
o IDs starting with a dash
o 以破折号开头的ID
o IDs starting with digits
o 以数字开头的ID
o IDs that contain only digits
o 仅包含数字的ID
o IDs that differ only by ASCII case (for example, A vs. a)
o 仅按ASCII大小写不同的ID（例如，A与A）
o the specific sequence of three characters NIL in any case (because this sequence can be confused with the IMAP protocol expression of the null value)
o 在任何情况下，三个字符的特定序列为NIL（因为此序列可能与null值的IMAP协议表达式相混淆）
A good solution to these issues is to prefix every ID with a single alphabetical character.
解决这些问题的一个好办法是在每个ID前面加一个字母字符。
The case of RENAME INBOX may need special handling because it has special behavior, as defined in [RFC3501], Section 6.3.5.
如[RFC3501]第6.3.5节所述，重命名收件箱的情况可能需要特殊处理，因为它具有特殊行为。
It is advisable (though not required) to have MAILBOXID be globally unique, but it is only required to be unique within messages offered to a single client login to a single server hostname. For example, a proxy that aggregates multiple independent servers MUST NOT advertise the OBJECTID capability unless it can guarantee that different objects will never use the same identifiers, even if backend object identifiers collide.
建议（尽管不是必需的）使MAILBOXID具有全局唯一性，但只要求在提供给单个客户端登录到单个服务器主机名的消息中具有唯一性。例如，聚合多个独立服务器的代理不得公布OBJECTID功能，除非它可以保证不同的对象永远不会使用相同的标识符，即使后端对象标识符发生冲突。
Servers that implement both RFC 6154 and this specification should optimize their execution of commands like UID SEARCH OR EMAILID 1234 EMAILID 4321.
实现RFC 6154和本规范的服务器应优化其对UID搜索或EMAILID 1234 EMAILID 4321等命令的执行。
Clients can assume that searching the all-mail mailbox using OR/ EMAILID or OR/THREADID is a fast way to find messages again if some other client has moved them out of the mailbox where they were previously seen.
如果其他客户端已将邮件从以前看到的邮箱中移出，则客户端可以假定使用或/EMAILID或或/THREADID搜索所有邮件邮箱是再次查找邮件的快速方法。
Clients that cache data offline should fetch the EMAILID of all new messages to avoid redownloading already-cached message details.
脱机缓存数据的客户端应获取所有新邮件的EMAILID，以避免重新下载已缓存的邮件详细信息。
Clients should fetch the MAILBOXID for any new mailboxes before discarding cache data for any mailbox that is no longer present on the server so that they can detect renames and avoid redownloading data.
客户端应在丢弃服务器上不再存在的任何邮箱的缓存数据之前获取任何新邮箱的MAILBOXID，以便能够检测重命名并避免重新下载数据。
In cases of server failure and disaster recovery, or misbehaving servers, it is possible that a client will be sent invalid information, e.g., identical ObjectIDs or ObjectIDs that have changed where they MUST NOT change according to this document.
如果服务器发生故障和灾难恢复，或者服务器行为不正常，则可能会向客户端发送无效信息，例如，相同的ObjectID或已更改的ObjectID，根据本文档，这些ObjectID不得更改。
In a case where a client detects inconsistent ObjectID responses from a server, it SHOULD fall back to relying on the guarantees of RFC 3501. For simplicity, a client MAY instead choose to discard its entire cache and resync all state from the server.
在客户端检测到来自服务器的不一致ObjectID响应的情况下，它应该返回到依赖RFC 3501的保证。为简单起见，客户机可以选择放弃其整个缓存，并从服务器重新同步所有状态。
Client authors protecting against server misbehavior MUST ensure that their design cannot get into an infinite loop of discarding cache and fetching the same data repeatedly without user interaction.
防止服务器错误行为的客户端作者必须确保他们的设计不会进入一个无限循环，即在没有用户交互的情况下丢弃缓存并重复获取相同的数据。
This extension is intentionally defined to be compatible with the data model in [JMAP-MAIL].
有意将此扩展定义为与[JMAP-MAIL]中的数据模型兼容。
A future extension could be proposed to give a way to SELECT a mailbox by MAILBOXID rather than name.
可以建议将来的扩展，以提供一种通过MAILBOXID而不是名称来选择邮箱的方法。
A future extension to [RFC5228] could allow fileinto by MAILBOXID rather than name.
[RFC5228]的未来扩展可能允许按MAILBOXID而不是名称进行文件导入。
An extension to allow fetching message content directly via EMAILID and message listings by THREADID could be proposed.
可以提出一个扩展，允许通过EMAILID直接获取消息内容，并通过THREADID获取消息列表。
IANA has added "OBJECTID" to the "IMAP Capabilities" registry located at <https://www.iana.org/assignments/imap-capabilities> with a reference to this document.
IANA已将“OBJECTID”添加到位于的“IMAP功能”注册表中<https://www.iana.org/assignments/imap-capabilities>参考本文件。
IANA has added "MAILBOXID" to the "IMAP Response Codes" registry located at <https://www.iana.org/assignments/imap-response-codes> with a reference to this document.
IANA已将“MAILBOXID”添加到位于的“IMAP响应代码”注册表中<https://www.iana.org/assignments/imap-response-codes>参考本文件。
It is strongly advised that servers generate ObjectIDs that are safe to use as filesystem names and unlikely to be autodetected as numbers. See implementation considerations.
强烈建议服务器生成objectid，这些objectid可以安全地用作文件系统名称，并且不太可能被自动检测为数字。见实施注意事项。
If a digest is used for ID generation, it must have a collision-resistant property, so server implementations are advised to monitor current security research and choose secure digests. As the IDs are generated by the server, it will be possible to migrate to a new hash by just using the new algorithm when creating new IDs. This is particularly true if a prefix is used on each ID, which can be changed when the algorithm changes.
如果摘要用于ID生成，它必须具有防冲突属性，因此建议服务器实现监视当前的安全研究并选择安全摘要。由于ID是由服务器生成的，因此在创建新ID时，只需使用新算法就可以迁移到新的哈希。如果在每个ID上使用前缀，则尤其如此，当算法更改时，前缀可以更改。
The use of a digest for ID generation may be used as proof that a particular sequence of bytes was seen by the server. However, this is only a risk if IDs are leaked to clients who don't have permission to fetch the data directly. Servers that are expected to handle highly sensitive data should consider this when choosing how to create IDs.
使用摘要生成ID可以证明服务器看到了特定的字节序列。但是，如果ID泄露给没有直接获取数据权限的客户端，这只是一种风险。希望处理高度敏感数据的服务器在选择如何创建IDS时应考虑这一点。
See also the security considerations in [RFC3501], Section 11.
另请参见[RFC3501]第11节中的安全注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 3501，DOI 10.17487/RFC3501，2003年3月<https://www.rfc-editor.org/info/rfc3501>.
[RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, December 2005, <https://www.rfc-editor.org/info/rfc4315>.
[RFC4315]Crispin，M.，“互联网消息访问协议（IMAP）-UIDPLUS扩展”，RFC 4315，DOI 10.17487/RFC4315，2005年12月<https://www.rfc-editor.org/info/rfc4315>.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, <https://www.rfc-editor.org/info/rfc4466>.
[RFC4466]Melnikov，A.和C.Daboo，“IMAP4 ABNF的收集扩展”，RFC 4466，DOI 10.17487/RFC4466，2006年4月<https://www.rfc-editor.org/info/rfc4466>.
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, January 2008, <https://www.rfc-editor.org/info/rfc5228>.
[RFC5228]Guenther，P.，Ed.和T.Showalter，Ed.，“筛选：电子邮件过滤语言”，RFC 5228，DOI 10.17487/RFC5228，2008年1月<https://www.rfc-editor.org/info/rfc5228>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, DOI 10.17487/RFC5256, June 2008, <https://www.rfc-editor.org/info/rfc5256>.
[RFC5256]Crispin，M.和K.Murchison，“互联网消息访问协议-排序和线程扩展”，RFC 5256，DOI 10.17487/RFC5256，2008年6月<https://www.rfc-editor.org/info/rfc5256>.
[RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for Returning STATUS Information in Extended LIST", RFC 5819, DOI 10.17487/RFC5819, March 2010, <https://www.rfc-editor.org/info/rfc5819>.
[RFC5819]Melnikov，A.和T.Sirainen，“扩展列表中返回状态信息的IMAP4扩展”，RFC 5819，DOI 10.17487/RFC5819，2010年3月<https://www.rfc-editor.org/info/rfc5819>.
[RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, DOI 10.17487/RFC6851, January 2013, <https://www.rfc-editor.org/info/rfc6851>.
[RFC6851]Gulbrandsen，A.和N.Freed，编辑，“互联网消息访问协议（IMAP）-移动扩展”，RFC 6851，DOI 10.17487/RFC6851，2013年1月<https://www.rfc-editor.org/info/rfc6851>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[JMAP-MAIL] Jenkins, N. and C. Newman, "JMAP for Mail", Work in Progress, draft-ietf-jmap-mail-07, August 2018.
[JMAP-MAIL]Jenkins，N.和C.Newman，“邮件的JMAP”，正在进行的工作，草稿-ietf-JMAP-MAIL-072018年8月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，DOI 10.17487/RFC4122，2005年7月<https://www.rfc-editor.org/info/rfc4122>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<https://www.rfc-editor.org/info/rfc4648>.
Ideas for calculating MAILBOXID:
计算MAILBOXID的思路：
o Universally Unique Identifier (UUID) [RFC4122]
o 通用唯一标识符（UUID）[RFC4122]
o Server-assigned sequence number (guaranteed not to be reused)
o 服务器分配的序列号（保证不重复使用）
Ideas for implementing EMAILID:
实施EMAILID的想法：
o Digest of message content (RFC822 bytes) -- expensive unless cached
o 消息内容摘要（RFC822字节）--除非缓存，否则代价高昂
o UUID [RFC4122]
o UUID[RFC4122]
o Server-assigned sequence number (guaranteed not to be reused)
o 服务器分配的序列号（保证不重复使用）
Ideas for implementing THREADID:
实现THREADID的想法：
o Derive from EMAILID of first seen message in the thread.
o 从线程中第一次看到的邮件的EMAILID派生。
o UUID [RFC4122]
o UUID[RFC4122]
o Server-assigned sequence number (guaranteed not to be reused)
o 服务器分配的序列号（保证不重复使用）
There is a need to index and look up reference/in-reply-to data at message creation to efficiently find matching messages for threading. Threading may be either across mailboxes or within each mailbox only. The server has significant leeway here.
在消息创建时，需要索引和查找引用/回复数据，以便高效地找到用于线程的匹配消息。线程可以跨邮箱执行，也可以仅在每个邮箱内执行。服务器在这里有很大的回旋余地。
Acknowledgments
致谢
The author would like to thank the EXTRA working group at IETF for feedback and advice -- in particular, Arnt Gulbrandsen, Brandon Long, Chris Newman, and Josef Sipek.
作者要感谢IETF额外工作组的反馈和建议，特别是Arnt Gulbrandsen、Brandon Long、Chris Newman和Josef Sipek。
This document drew inspiration from the Gmail X-GM-THRID and X-GM-MSGID implementations as currently defined at <https://developers.google.com/gmail/imap/imap-extensions>, as well as the X-GUID implementation in the Dovecot server.
本文档从Gmail X-GM-THRID和X-GM-MSGID的实现中获得了灵感，目前在<https://developers.google.com/gmail/imap/imap-extensions>，以及Dovecot服务器中的X-GUID实现。
Author's Address
作者地址
Bron Gondwana (editor) FastMail Level 2, 114 William St Melbourne VIC 3000 Australia
布隆冈瓦纳（编辑）快信2层，114威廉街墨尔本维多利亚3000澳大利亚
Email: brong@fastmailteam.com
URI: https://www.fastmail.com
Email: brong@fastmailteam.com
URI: https://www.fastmail.com