Network Working Group M. Crispin
Request for Comments: 3502 University of Washington
Category: Standards Track March 2003
Network Working Group M. Crispin
Request for Comments: 3502 University of Washington
Category: Standards Track March 2003
Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
Internet消息访问协议（IMAP）-多附加扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server.
本文档描述了Internet消息访问协议（IMAP）（RFC 3501）的多附件扩展。此扩展为IMAP客户端提供了实质性的性能改进，这些客户端一次将多个邮件上载到服务器上的邮箱。
A server which supports this extension indicates this with a capability name of "MULTIAPPEND".
支持此扩展的服务器使用功能名称“MULTIAPPEND”表示此扩展。
Terminology
术语
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“可”和“可选”应按照[关键词]中的说明进行解释。
Introduction
介绍
The MULTIAPPEND extension permits uploading of multiple messages with a single command. When used in conjunction with the [LITERAL+] extension, the entire upload is accomplished in a single command/response round trip.
MULTIAPPEND扩展允许使用单个命令上载多条消息。当与[LITERAL+]扩展一起使用时，整个上载过程在单个命令/响应往返过程中完成。
A MULTIAPPEND APPEND operation is atomic; either all messages are successfully appended, or no messages are appended.
多附加操作是原子的；成功附加所有消息，或者不附加任何消息。
In the base IMAP specification, each message must be appended in a separate command, and there is no mechanism to "unappend" messages if an error occurs while appending. Also, some mail stores may require
在基本IMAP规范中，每条消息都必须附加在单独的命令中，如果在附加时发生错误，则没有“取消发送”消息的机制。此外，一些邮件商店可能需要
an expensive "open/lock + sync/unlock/close" operation as part of appending; this can be quite expensive if it must be done on a per-message basis.
作为附加的一部分，一个昂贵的“打开/锁定+同步/解锁/关闭”操作；如果必须按每条消息执行，那么这可能会非常昂贵。
If the server supports both LITERAL+ and pipelining but not MULTIAPPEND, it may be possible to get some of the performance advantages of MULTIAPPEND by doing a pipelined "batch" append. However, it will not work as well as MULTIAPPEND for the following reasons:
如果服务器同时支持LITERAL+和pipeline，但不支持MULTIAPPEND，那么可以通过执行流水线“批处理”追加来获得MULTIAPPEND的一些性能优势。但是，由于以下原因，它不能像MULTIAPPEND那样工作：
1) Multiple APPEND commands, even as part of a pipelined batch, are non-atomic by definition. There is no way to revert the mailbox to the state before the batch append in the event of an error.
1) 根据定义，多个APPEND命令（即使作为流水线批处理的一部分）是非原子的。发生错误时，无法将邮箱恢复到批处理追加之前的状态。
2) It may not be feasible for the server to coalesce pipelined APPEND operations so as to avoid the "open/lock + sync/unlock/close" overhead described above. In any case, such coalescing would be timing dependent and thus potentially unreliable. In particular, with traditional UNIX mailbox files, it is assumed that a lock is held only for a single atomic operation, and many applications disregard any lock that is older than 5 minutes.
2) 服务器合并流水线附加操作以避免上述“打开/锁定+同步/解锁/关闭”开销可能是不可行的。在任何情况下，这种合并都将依赖于时间，因此可能不可靠。特别是，对于传统的UNIX邮箱文件，假定只为单个原子操作持有一个锁，并且许多应用程序忽略任何超过5分钟的锁。
3) If an error occurs, depending upon the nature of the error, it is possible for additional messages to be appended after the error. For example, the user wants to append 5 messages, but a disk quota error occurs with the third message because of its size. However, the fourth and fifth messages have already been sent in the pipeline, so the mailbox ends up with the first, second, fourth, and fifth messages of the batch appended.
3) 如果发生错误，根据错误的性质，可能会在错误后追加其他消息。例如，用户希望附加5条消息，但由于第三条消息的大小，因此会发生磁盘配额错误。但是，第四条和第五条消息已经在管道中发送，因此邮箱最后会追加批处理的第一条、第二条、第四条和第五条消息。
Arguments: mailbox name one or more messages to upload, specified as: OPTIONAL flag parenthesized list OPTIONAL date/time string message literal
参数：邮箱名称一个或多个要上载的邮件，指定为：可选标志括号列表可选日期/时间字符串邮件文本
Data: no specific responses for this command
数据：此命令没有特定响应
Result: OK - append completed NO - append error: can't append to that mailbox, error in flags or date/time or message text, append cancelled BAD - command unknown or arguments invalid
结果：确定-追加完成否-追加错误：无法追加到该邮箱，标志或日期/时间或消息文本错误，追加已取消错误-命令未知或参数无效
The APPEND command appends the literal arguments as new messages to the end of the specified destination mailbox. This argument SHOULD be in the format of an [RFC-2822] message. 8-bit characters are permitted in the message. A server implementation that is unable to preserve 8-bit data properly MUST be able to reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content transfer encoding.
APPEND命令将文字参数作为新消息追加到指定目标邮箱的末尾。此参数的格式应为[RFC-2822]消息。消息中允许使用8位字符。无法正确保留8位数据的服务器实现必须能够使用[MIME-IMB]内容传输编码将8位追加数据可逆地转换为7位。
Note: There MAY be exceptions, e.g., draft messages, in which required [RFC-2822] header lines are omitted in the message literal argument to APPEND. The full implications of doing so MUST be understood and carefully weighed.
注意：可能存在例外情况，例如，草稿消息，其中需要追加的消息文字参数中省略了所需的[RFC-2822]头行。必须理解并仔细权衡这样做的全部影响。
If a flag parenthesized list is specified, the flags SHOULD be set in the resulting message; otherwise, the flag list of the resulting message is set empty by default.
如果指定了带括号的标记列表，则应在生成的消息中设置标记；否则，结果消息的标志列表默认设置为空。
If a date-time is specified, the internal date SHOULD be set in the resulting message; otherwise, the internal date of the resulting message is set to the current date and time by default.
如果指定了日期时间，则应在生成的消息中设置内部日期；否则，结果消息的内部日期默认设置为当前日期和时间。
A zero-length message literal argument is an error, and MUST return a NO. This can be used to cancel the append.
长度为零的消息文字参数是错误的，必须返回“否”。这可用于取消追加。
If the append is unsuccessful for any reason (including being cancelled), the mailbox MUST be restored to its state before the APPEND attempt; no partial appending is permitted. The server MAY return an error before processing all the message arguments.
如果由于任何原因（包括被取消）追加失败，则必须将邮箱恢复到追加尝试之前的状态；不允许部分附加。在处理所有消息参数之前，服务器可能会返回错误。
If the destination mailbox does not exist, a server MUST return an error, and MUST NOT automatically create the mailbox. Unless it is certain that the destination mailbox can not be created, the server MUST send the response code "[TRYCREATE]" as the prefix of the text of the tagged NO response. This gives a hint to the client that it can attempt a CREATE command and retry the APPEND if the CREATE is successful.
如果目标邮箱不存在，服务器必须返回错误，并且不能自动创建邮箱。除非确定无法创建目标邮箱，否则服务器必须发送响应代码“[TRYCREATE]”，作为标记的无响应文本的前缀。这会提示客户端，如果创建成功，它可以尝试创建命令并重试追加。
If the mailbox is currently selected, the normal new message actions SHOULD occur. Specifically, the server SHOULD notify the client immediately via an untagged EXISTS response. If the server does not do so, the client MAY issue a NOOP command (or failing that, a CHECK command) after one or more APPEND commands.
如果当前选择了邮箱，则应执行正常的新邮件操作。具体地说，服务器应该通过未标记的EXISTS响应立即通知客户机。如果服务器不这样做，客户机可能会在一个或多个APPEND命令之后发出NOOP命令（否则，发出CHECK命令）。
Example: C: A003 APPEND saved-messages (\Seen) {329}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.example.net
C: Message-Id: <B27397-0100000@Blurdybloop.example.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C: (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
C: From: Joe Mooch <mooch@OWaTaGu.example.net>
C: Subject: Re: afternoon meeting
C: To: foobar@blurdybloop.example.com
C: Message-Id: <a0434793874930@OWaTaGu.example.net>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: 3:30 is fine with me.
C:
S: A003 OK APPEND completed
C: A004 APPEND bogusname (\Flagged) {1023}
S: A004 NO [TRYCREATE] No such mailbox as bogusname
C: A005 APPEND test (\Flagged) {99}
S: + Ready for literal data
C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
C: From: Fred Foobar <fred@example.com>
C: Subject: hmm...
C: {35403}
S: A005 NO APPEND failed: Disk quota exceeded
Example: C: A003 APPEND saved-messages (\Seen) {329}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.example.net
C: Message-Id: <B27397-0100000@Blurdybloop.example.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C: (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
C: From: Joe Mooch <mooch@OWaTaGu.example.net>
C: Subject: Re: afternoon meeting
C: To: foobar@blurdybloop.example.com
C: Message-Id: <a0434793874930@OWaTaGu.example.net>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: 3:30 is fine with me.
C:
S: A003 OK APPEND completed
C: A004 APPEND bogusname (\Flagged) {1023}
S: A004 NO [TRYCREATE] No such mailbox as bogusname
C: A005 APPEND test (\Flagged) {99}
S: + Ready for literal data
C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
C: From: Fred Foobar <fred@example.com>
C: Subject: hmm...
C: {35403}
S: A005 NO APPEND failed: Disk quota exceeded
Note: The APPEND command is not used for message delivery, because it does not provide a mechanism to transfer [SMTP] envelope information.
注意：APPEND命令不用于邮件传递，因为它不提供传输[SMTP]信封信息的机制。
Modification to IMAP4rev1 Base Protocol Formal Syntax
对IMAP4rev1基本协议形式语法的修改
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下语法规范使用[ABNF]中指定的增广Backus Naur Form（ABNF）表示法。
append = "APPEND" SP mailbox 1*append-message
append=“append”SP邮箱1*追加邮件
append-message = [SP flag-list] [SP date-time] SP literal
append-message = [SP flag-list] [SP date-time] SP literal
MULTIAPPEND Interaction with UIDPLUS Extension
与UIDPLUS扩展的多附加交互
Servers which support both MULTIAPPEND and [UIDPLUS] will have the "resp-code-apnd" rule modified as follows:
同时支持MULTIAPPEND和[UIDPLUS]的服务器将修改“resp code apnd”规则，如下所示：
resp-code-apnd = "APPENDUID" SP nz-number SP set
响应代码apnd=“APPENDUID”SP nz编号SP集合
That is, the APPENDUID response code returns as many UIDs as there were messages appended in the multiple append. The UIDs returned should be in the order the articles where appended. The message set may not contain extraneous UIDs or the symbol "*".
也就是说，APPENDUID响应代码返回的UID数量与多重追加中追加的消息数量相同。返回的UID应该按照文章的附加顺序。消息集不能包含无关的UID或符号“*”。
Security Considerations
安全考虑
The MULTIAPPEND extension does not raise any security considerations that are not present in the base [IMAP] protocol, and these issues are discussed in [IMAP]. Nevertheless, it is important to remember that IMAP4rev1 protocol transactions, including electronic mail data, are sent in the clear over the network unless protection from snooping is negotiated, either by the use of STARTTLS, privacy protection is negotiated in the AUTHENTICATE command, or some other protection mechanism is in effect.
MULTIAPPEND扩展不会引起任何在基本[IMAP]协议中不存在的安全问题，这些问题将在[IMAP]中讨论。尽管如此，重要的是要记住，IMAP4rev1协议事务（包括电子邮件数据）是通过网络以明文形式发送的，除非通过使用STARTTLS协商防止窥探，或者在AUTHENTICATE命令中协商隐私保护，或者某些其他保护机制有效。
Normative References
规范性引用文件
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME-IMB]Freed，N.和N.Borenstein，“MIME（多用途互联网邮件扩展）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC-2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
Informative References
资料性引用
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[LITERAL+]Myers，J.，“IMAP4非同步文字”，RFC2088，1997年1月。
[UIDPLUS] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988.
[UIDPLUS]迈尔斯，J.，“IMAP4 UIDPLUS扩展”，RFC 23591988年6月。
[SMTP] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP]Klensin，J.，编辑，“简单邮件传输协议”，RFC 28212001年4月。
Author's Address
作者地址
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
Mark R. Crispin网络与分布式计算华盛顿大学西雅图第十五大街4545号WA98105-427
Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU
电话：（206）543-5762电子邮件：MRC@CAC.Washington.EDU
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。