Internet Engineering Task Force (IETF) S. Brandt
Request for Comments: 8508 Verizon
Category: Standards Track January 2019
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Brandt
Request for Comments: 8508 Verizon
Category: Standards Track January 2019
ISSN: 2070-1721
IMAP REPLACE Extension
IMAP替换扩展
Abstract
摘要
This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them.
本文档定义了一个IMAP扩展，可用于将消息存储中的现有消息替换为新消息。消息替换是客户机的常见操作，客户机在用户编写草稿或注释时自动保存草稿或注释。
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/rfc8508.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8508.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. REPLACE and UID REPLACE . . . . . . . . . . . . . . . . . . . 3
3.1. Advertising Support for REPLACE . . . . . . . . . . . . . 3
3.2. REPLACE Command . . . . . . . . . . . . . . . . . . . . . 3
3.3. UID REPLACE Command . . . . . . . . . . . . . . . . . . . 4
3.4. Semantics of REPLACE and UID REPLACE . . . . . . . . . . 5
3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 6
4. Interaction with Other Extensions . . . . . . . . . . . . . . 6
4.1. ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. CATENATE . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. UIDPLUS . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. IMAP Events in Sieve . . . . . . . . . . . . . . . . . . 8
4.5. CONDSTORE/QRESYNC . . . . . . . . . . . . . . . . . . . . 8
4.6. OBJECTID . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. MULTIAPPEND . . . . . . . . . . . . . . . . . . . . . . . 8
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. REPLACE and UID REPLACE . . . . . . . . . . . . . . . . . . . 3
3.1. Advertising Support for REPLACE . . . . . . . . . . . . . 3
3.2. REPLACE Command . . . . . . . . . . . . . . . . . . . . . 3
3.3. UID REPLACE Command . . . . . . . . . . . . . . . . . . . 4
3.4. Semantics of REPLACE and UID REPLACE . . . . . . . . . . 5
3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 6
4. Interaction with Other Extensions . . . . . . . . . . . . . . 6
4.1. ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. CATENATE . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. UIDPLUS . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. IMAP Events in Sieve . . . . . . . . . . . . . . . . . . 8
4.5. CONDSTORE/QRESYNC . . . . . . . . . . . . . . . . . . . . 8
4.6. OBJECTID . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. MULTIAPPEND . . . . . . . . . . . . . . . . . . . . . . . 8
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
This document defines an IMAP ([RFC3501]) extension to facilitate the replacement of an existing message with a new one. This is accomplished by defining a new REPLACE command and extending the Unique Identifier (UID) command to allow UID REPLACE.
本文档定义了IMAP（[RFC3501]）扩展，以便于用新消息替换现有消息。这是通过定义一个新的REPLACE命令并扩展惟一标识符（UID）命令以允许UID REPLACE来实现的。
Since there is no replace function in the base IMAP specification, clients have instead had to use a combination of three separate commands issued in serial fashion; APPEND, STORE, and EXPUNGE. Pipelining of these three commands is not recommended since failure of any individual command should prevent subsequent commands from being executed lest the original message version be lost.
由于基本IMAP规范中没有替换功能，因此客户端不得不使用以串行方式发出的三个单独命令的组合；附加、存储和删除。不建议使用这三个命令的管道，因为任何单个命令的失败都会阻止后续命令的执行，以免丢失原始消息版本。
Because of the non-atomic nature of the existing sequence, interruptions can leave messages in intermediate states that can be seen and acted upon by other clients. Such interruptions can also strand older revisions of messages, thereby forcing the user to manually clean up multiple revisions of the same message in order to avoid wasteful quota consumption. Additionally, the existing sequence can fail on APPEND due to an over-quota condition even
由于现有序列的非原子性质，中断会使消息处于中间状态，其他客户端可以看到并对其进行操作。这种中断还可以将旧版本的消息串在一起，从而迫使用户手动清理同一消息的多个版本，以避免浪费配额消耗。此外，现有序列在追加时可能会由于超出配额条件而失败
though the subsequent STORE/EXPUNGE would free up enough space for the newly revised message. And finally, server efficiencies may be possible with a single logical message replacement operation as compared to the existing APPEND/STORE/EXPUNGE sequence.
尽管后续的存储/删除操作将为新修改的邮件释放足够的空间。最后，与现有的APPEND/STORE/EXPUNGE序列相比，使用单个逻辑消息替换操作可以提高服务器效率。
In its simplest form, the REPLACE command is a single-command encapsulation of APPEND, STORE +flags \DELETED, and UID EXPUNGE for a message, except that it avoids any of the quota implications or intermediate states associated with the three-command sequence. Server developers are encouraged to implement REPLACE as an atomic operation to simplify error handling, minimize operational concerns, and reduce potential security problems. For systems where this is not possible, communication with the requesting client must ensure no confusion of message store state. A server MUST NOT generate a response code for the STORE +flags \DELETED portion of the sequence. Additionally, servers supporting the REPLACE command MUST NOT infer any inheritance of content, flags, or annotations from the message being replaced.
在最简单的形式中，REPLACE命令是消息的APPEND、STORE+flags\DELETED和UID EXPUNGE的单个命令封装，只是它避免了与这三个命令序列关联的任何配额含义或中间状态。我们鼓励服务器开发人员将REPLACE作为一个原子操作来实现，以简化错误处理、最小化操作问题并减少潜在的安全问题。对于不可能实现这一点的系统，与请求客户端的通信必须确保不会混淆消息存储状态。服务器不得为序列的STORE+flags\ DELETED部分生成响应代码。此外，支持REPLACE命令的服务器不得从被替换的消息推断任何内容、标志或注释的继承。
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]所述进行解释。
Formal syntax is defined by [RFC5234].
形式语法由[RFC5234]定义。
Example lines prefaced by "C:" are sent by the client, and ones prefaced by "S:" are sent by the server.
以“C:”开头的示例行由客户端发送，以“S:”开头的示例行由服务器发送。
Servers that implement the REPLACE extension will return "REPLACE" as one of the supported capabilities in the CAPABILITY command response.
实现REPLACE扩展的服务器将在CAPABILITY命令响应中返回“REPLACE”作为支持的功能之一。
Arguments: message sequence number mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string message literal
参数：消息序列号邮箱名称可选标志括号列表可选日期/时间字符串消息文字
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - replace completed NO - replace error; can't remove specified message or can't add new message content BAD - command unknown or arguments invalid
结果：正常-更换完成无更换错误；无法删除指定的消息或无法添加新消息内容错误-命令未知或参数无效
Example:
C: A003 REPLACE 4 Drafts (\Seen \Draft) {312}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !!
C: To: miss.mitzy@example.org
C: Message-Id: <B238822388-0100000@example.org>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Just saw the best fireworks show. Wish you were here.
C:
S: * OK [APPENDUID 1 2000] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A003 OK Replace completed
Example:
C: A003 REPLACE 4 Drafts (\Seen \Draft) {312}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !!
C: To: miss.mitzy@example.org
C: Message-Id: <B238822388-0100000@example.org>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Just saw the best fireworks show. Wish you were here.
C:
S: * OK [APPENDUID 1 2000] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A003 OK Replace completed
This extends the first form of the UID command (see Section 6.4.8 of [RFC3501]) to add the REPLACE command defined above as a valid argument. This form of REPLACE uses a UID rather than a sequence number as its first parameter.
这扩展了UID命令的第一种形式（参见[RFC3501]第6.4.8节），以添加上面定义的替换命令作为有效参数。这种形式的REPLACE使用UID而不是序列号作为其第一个参数。
Example:
C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !!
C: To: miss.mitzy@example.org
C: Message-Id: <B238822389-0100000@example.org>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Just saw the best fireworks show. Wish you were here.
C: Hopefully next year you can join us.
C:
S: * OK [APPENDUID 1 2001] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A004 OK Replace completed
Example:
C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !!
C: To: miss.mitzy@example.org
C: Message-Id: <B238822389-0100000@example.org>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Just saw the best fireworks show. Wish you were here.
C: Hopefully next year you can join us.
C:
S: * OK [APPENDUID 1 2001] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A004 OK Replace completed
The REPLACE and UID REPLACE commands take five arguments: a message identifier, a named mailbox, an optional parenthesized flag list, an optional message date/time string, and a message literal. The message literal will be appended to the named mailbox, and the message specified by the message identifier will be removed from the selected mailbox. These operations will appear to the client as a single action. This has the same effect as the following sequence:
REPLACE和UID REPLACE命令有五个参数：消息标识符、命名邮箱、可选括号标志列表、可选消息日期/时间字符串和消息文本。消息文字将附加到命名邮箱，并且由消息标识符指定的消息将从所选邮箱中删除。这些操作将在客户端显示为单个操作。这与以下顺序具有相同的效果：
1. APPEND 2. [UID] STORE +FLAGS.SILENT \DELETED 3. UID EXPUNGE
1. 附加2。[UID]STORE+FLAGS.SILENT\3已删除。UID清除
In the cited sequence, the quota implications of APPEND are evaluated within the context of the pending EXPUNGE so that only the net quota consumption is considered. Additionally, the EXPUNGE portion of the sequence only applies to the specified message, not all messages flagged as "\Deleted".
在引用的顺序中，APPEND的配额影响在待删除的上下文中进行评估，以便只考虑净配额消耗。此外，序列的删除部分仅适用于指定的消息，而不是标记为“\Deleted”的所有消息。
Although the effect of REPLACE is identical to the steps above, the semantics are not identical; similar to MOVE [RFC6851], the intermediate states do not occur and the response codes are different. In particular, the response codes for APPEND and EXPUNGE will be returned while those for the STORE operation MUST NOT be generated.
替换的效果虽然与上述步骤相同，但语义不尽相同；与MOVE[RFC6851]类似，中间状态不会出现，响应代码也不同。特别是，APPEND和EXPUNGE的响应代码将被返回，而STORE操作的响应代码不得生成。
When an error occurs while processing REPLACE or UID REPLACE, the server MUST NOT leave the selected mailbox in an inconsistent state; any untagged EXPUNGE response MUST NOT be sent until all actions are successfully completed.
当处理REPLACE或UID REPLACE时出错时，服务器不得使所选邮箱处于不一致状态；在所有操作成功完成之前，不得发送任何未标记的删除响应。
While it may be common for the named mailbox argument to match the selected mailbox for the common use case of replacing a draft, the REPLACE extension intentionally does not require the two to be the same. As an example, it's possible to use the REPLACE command to replace a message in the \Drafts special-use mailbox (see Section 2 of [RFC6154]) with a message in the \Sent special-use mailbox following message submission.
对于替换草稿的常见用例，命名邮箱参数与所选邮箱匹配可能很常见，但替换扩展故意不要求两者相同。例如，在提交邮件后，可以使用REPLACE命令将\Drafts专用邮箱中的邮件（请参阅[RFC6154]第2节）替换为\Sent专用邮箱中的邮件。
Because of the similarity of REPLACE to APPEND, extensions that affect APPEND affect REPLACE in the same way. Response codes such as TRYCREATE (see Section 6.3.11 of [RFC3501]), along with those defined by extensions, are sent as appropriate. See Section 4 for more information about how REPLACE interacts with other IMAP extensions.
由于REPLACE与APPEND的相似性，影响APPEND的扩展以相同的方式影响REPLACE。响应代码，如TRYCREATE（见[RFC3501]第6.3.11节），以及扩展定义的代码，视情况发送。有关REPLACE如何与其他IMAP扩展交互的更多信息，请参见第4节。
Unlike the APPEND command, which is valid in the authenticated state, the REPLACE and UID REPLACE commands MUST only be valid in the selected state. This difference from APPEND is necessary since REPLACE operates on message sequence numbers. Additionally, the REPLACE extension intentionally follows the convention for UID commands found in Section 6.4.8 of [RFC3501] in that the UID variant of the command does not support use from the authenticated state.
与APPEND命令（在已验证状态下有效）不同，REPLACE和UID REPLACE命令必须仅在选定状态下有效。由于REPLACE对消息序列号进行操作，因此与APPEND的这种差异是必要的。此外，REPLACE扩展有意遵循[RFC3501]第6.4.8节中UID命令的约定，因为该命令的UID变量不支持从认证状态使用。
This section describes how REPLACE interacts with some other IMAP extensions.
本节介绍REPLACE如何与其他一些IMAP扩展交互。
The Access Control List (ACL) rights [RFC4314] required for UID REPLACE are the union of the ACL rights required for UID STORE and UID EXPUNGE in the current mailbox, and APPEND in the target mailbox.
UID替换所需的访问控制列表（ACL）权限[RFC4314]是当前邮箱中UID存储和UID删除所需的ACL权限的并集，并附加到目标邮箱中。
Servers supporting both REPLACE and CATENATE [RFC4469] MUST support the additional append-data and resp-text-code elements defined in Section 5 ("Formal Syntax") of [RFC4469] in conjunction with the REPLACE command. When combined with CATENATE, REPLACE can become quite an efficient way of message manipulation.
支持REPLACE和CATENATE[RFC4469]的服务器必须支持[RFC4469]第5节（“形式语法”）中定义的附加附加数据和resp文本代码元素以及REPLACE命令。当与CATENATE结合使用时，REPLACE可以成为一种非常有效的消息处理方式。
Example:
例子：
User composes message and attaches photo
----------------------------------------
C: A010 APPEND Drafts (\Seen \Draft) {1201534}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Message-ID: <B238822388-0100003@example.org>
C: MIME-Version: 1.0
C: Content-Type: multipart/mixed;
C: boundary="------------030305060306060609050804"
C:
C: --------------030305060306060609050804
C: Content-Type: text/plain; charset=utf-8; format=flowed
C: Content-Transfer-Encoding: 7bit
C:
C: Here is picture from the fireworks
C:
C: Yours...
C: Fritz
C:
C: --------------030305060306060609050804
C: Content-Type: image/jpeg;
C: name="Fireworks.jpg"
C: Content-Transfer-Encoding: base64
C: Content-Disposition: attachment;
C: filename="Fireworks.jpg"
C:
<large base64 encoded part goes here>
C:
C: --------------030305060306060609050804--
S: A010 OK [APPENDUID 1 3002] APPEND complete
User composes message and attaches photo
----------------------------------------
C: A010 APPEND Drafts (\Seen \Draft) {1201534}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Message-ID: <B238822388-0100003@example.org>
C: MIME-Version: 1.0
C: Content-Type: multipart/mixed;
C: boundary="------------030305060306060609050804"
C:
C: --------------030305060306060609050804
C: Content-Type: text/plain; charset=utf-8; format=flowed
C: Content-Transfer-Encoding: 7bit
C:
C: Here is picture from the fireworks
C:
C: Yours...
C: Fritz
C:
C: --------------030305060306060609050804
C: Content-Type: image/jpeg;
C: name="Fireworks.jpg"
C: Content-Transfer-Encoding: base64
C: Content-Disposition: attachment;
C: filename="Fireworks.jpg"
C:
<large base64 encoded part goes here>
C:
C: --------------030305060306060609050804--
S: A010 OK [APPENDUID 1 3002] APPEND complete
User completes message with To: and Subject: fields
---------------------------------------------------
C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71}
S: + Ready for literal data
C: To: Mitzy <miss.mitzy@example.org>
C: Subject: My view of the fireworks
C: URL "/Drafts/;UID=3002")
S: * OK [APPENDUID 1 3003] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A011 OK REPLACE completed
User completes message with To: and Subject: fields
---------------------------------------------------
C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71}
S: + Ready for literal data
C: To: Mitzy <miss.mitzy@example.org>
C: Subject: My view of the fireworks
C: URL "/Drafts/;UID=3002")
S: * OK [APPENDUID 1 3003] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A011 OK REPLACE completed
Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send APPENDUID in response to a UID REPLACE command. For additional information, see Section 3 of [RFC4315]. Servers implementing REPLACE and UIDPLUS are also advised to send the APPENDUID response code in an untagged OK before sending the EXPUNGE or replaced responses. (Sending APPENDUID in the tagged OK as described in the UIDPLUS specification means that the client first receives EXPUNGE for a message and afterwards APPENDUID for the new message. It can be unnecessarily difficult to process that sequence usefully.)
支持REPLACE和UIDPLUS[RFC4315]的服务器应发送APPENDUID以响应UID REPLACE命令。有关更多信息，请参见[RFC4315]第3节。还建议实现REPLACE和UIDPLUS的服务器在发送“删除”或“替换”响应之前，以未标记的“确定”形式发送APPENDUID响应代码。（如UIDPLUS规范中所述，在标记好的OK中发送APPENDUID意味着客户端首先接收消息的EXPUNGE，然后再接收新消息的APPENDUID。有效地处理该序列可能会有不必要的困难。）
REPLACE applies to IMAP events in Sieve [RFC6785] in the same way that APPEND does. Therefore, REPLACE can cause a Sieve script to be invoked with the imap.cause set to "APPEND". Because the intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by REPLACE, no action will be taken that results in an imap.cause of FLAG.
REPLACE应用于Sieve[RFC6785]中的IMAP事件，方式与APPEND相同。因此，REPLACE会导致在imap.cause设置为“APPEND”的情况下调用筛选脚本。由于REPLACE未公开STORE+FLAGS.SILENT\DELETED的中间状态，因此不会采取导致标志出现imap.cause的任何操作。
Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] MUST treat the message being replaced as if it were being removed with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of [RFC7162] are particularly relevant for this condition.
同时实现REPLACE和CONDSTORE/QRESYNC[RFC7162]的服务器必须将被替换的消息视为使用UID EXPUNGE命令将其删除。[RFC7162]第3.2.9节和第3.2.10节特别适用于这种情况。
Servers implementing both REPLACE and OBJECTID [RFC8474] MUST return different EMAILIDs for both the replaced and replacing messages. The only exception to this is the case outlined in Section 5.1 ("EMAILID Identifier for Identical Messages") of [RFC8474] when the server detects that both messages' immutable content is identical.
同时实现REPLACE和OBJECTID[RFC8474]的服务器必须为替换和替换邮件返回不同的EmailID。唯一的例外情况是[RFC8474]第5.1节（“相同邮件的EMAILID标识符”）中概述的情况，即服务器检测到两条邮件的不可变内容相同。
The REPLACE extension has no interaction with MULTIAPPEND [RFC3502]. This document explicitly does not outline a method for replacing multiple messages concurrently.
REPLACE扩展与MULTIAPPEND[RFC3502]没有交互。本文档没有明确概述同时替换多条消息的方法。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability","command-select", "mailbox", "seq-number", and "uid". [RFC4466] defines the non-terminal "append-message".
以下语法规范使用[RFC5234]中指定的增广巴科斯诺尔形式（ABNF）表示法。[RFC3501]定义非终端“能力”、“命令选择”、“邮箱”、“序号”和“uid”。[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.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅用于编辑清晰性。实现必须以不区分大小写的方式接受这些字符串。
capability =/ "REPLACE"
功能=/“替换”
command-select =/ replace
replace = "REPLACE" SP seq-number SP mailbox append-message
uid =/ "UID" SP replace
command-select =/ replace
replace = "REPLACE" SP seq-number SP mailbox append-message
uid =/ "UID" SP replace
This document is believed to add no security problems beyond those that may already exist with the base IMAP specification. The REPLACE command may actually prevent some potential security problems because it avoids intermediate message states that could possibly be exploited by an attacker.
除了基本IMAP规范中可能已经存在的安全问题外，本文档不会添加任何其他安全问题。REPLACE命令实际上可以防止一些潜在的安全问题，因为它避免了攻击者可能利用的中间消息状态。
The IANA has added REPLACE to the "IMAP Capabilities" registry at <https://www.iana.org/assignments/imap-capabilities>.
IANA已在“IMAP功能”注册表中添加了替换<https://www.iana.org/assignments/imap-capabilities>.
[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>.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, DOI 10.17487/RFC4314, December 2005, <https://www.rfc-editor.org/info/rfc4314>.
[RFC4314]Melnikov，A.，“IMAP4访问控制列表（ACL）扩展”，RFC 4314，DOI 10.17487/RFC4314，2005年12月<https://www.rfc-editor.org/info/rfc4314>.
[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>.
[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 2006, <https://www.rfc-editor.org/info/rfc4469>.
[RFC4469]Resnick，P.，“互联网消息访问协议（IMAP）连锁扩展”，RFC 4469，DOI 10.17487/RFC4469，2006年4月<https://www.rfc-editor.org/info/rfc4469>.
[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>.
[RFC6785] Leiba, B., "Support for Internet Message Access Protocol (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, November 2012, <https://www.rfc-editor.org/info/rfc6785>.
[RFC6785]Leiba，B.，“互联网消息访问协议（IMAP）事件在筛中的支持”，RFC 6785，DOI 10.17487/RFC67852012年11月<https://www.rfc-editor.org/info/rfc6785>.
[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)", RFC 7162, DOI 10.17487/RFC7162, May 2014, <https://www.rfc-editor.org/info/rfc7162>.
[RFC7162]Melnikov，A.和D.Cridland，“IMAP扩展：快速标志更改再同步（CONDSTORE）和快速邮箱再同步（QRESYNC）”，RFC 7162，DOI 10.17487/RFC7162，2014年5月<https://www.rfc-editor.org/info/rfc7162>.
[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>.
[RFC8474] Gondwana, B., Ed., "IMAP Extension for Object Identifiers", RFC 8474, DOI 10.17487/RFC8474, September 2018, <https://www.rfc-editor.org/info/rfc8474>.
[RFC8474]冈瓦纳，B.，编辑，“对象标识符的IMAP扩展”，RFC 8474，DOI 10.17487/RFC8474，2018年9月<https://www.rfc-editor.org/info/rfc8474>.
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502, March 2003, <https://www.rfc-editor.org/info/rfc3502>.
[RFC3502]Crispin，M.，“互联网消息访问协议（IMAP）-多附加扩展”，RFC 3502，DOI 10.17487/RFC3502，2003年3月<https://www.rfc-editor.org/info/rfc3502>.
[RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, March 2011, <https://www.rfc-editor.org/info/rfc6154>.
[RFC6154]Leiba，B.和J.Nicolson，“特殊用途邮箱的IMAP列表扩展”，RFC 6154，DOI 10.17487/RFC6154，2011年3月<https://www.rfc-editor.org/info/rfc6154>.
[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>.
Acknowledgements
致谢
The author would like to thank the participants of IMAPEXT with particular thanks to Arnt Gulbrandsen, Alexey Melnikov, Chris Newman, and Bron Gondwana for their specific contributions.
作者要感谢IMAPEXT的参与者，特别感谢Arnt Gulbrandsen、Alexey Melnikov、Chris Newman和Bron Gondwana的具体贡献。
Author's Address
作者地址
Stuart Brandt Verizon 22001 Loudoun County Parkway Ashburn, VA 20147 United States of America
斯图尔特·勃兰特·威瑞森22001美国弗吉尼亚州阿什本市劳顿县公园路20147
Email: stujenerin@aol.com
Email: stujenerin@aol.com