Network Working Group D. Cridland, Ed.
Request for Comments: 5550 A. Melnikov, Ed.
Obsoletes: 4550 Isode Limited
Updates: 4469, 4467 S. Maes, Ed.
Category: Standards Track Oracle
August 2009
Network Working Group D. Cridland, Ed.
Request for Comments: 5550 A. Melnikov, Ed.
Obsoletes: 4550 Isode Limited
Updates: 4469, 4467 S. Maes, Ed.
Category: Standards Track Oracle
August 2009
The Internet Email to Support Diverse Service Environments (Lemonade) Profile
支持不同服务环境的Internet电子邮件（柠檬水）配置文件
Abstract
摘要
This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.
本文档描述了IMAP、邮件提交和筛选协议的概要文件（一组必需的扩展、限制和使用模式），称为Lemonade。此配置文件允许客户端（特别是那些在内存、带宽、处理能力或其他方面受到限制的客户端）高效地使用IMAP和Submission来访问和提交邮件。这包括转发收到的邮件而无需下载和上载邮件、优化提交以及在与服务器失去连接时高效地重新同步的能力。
The Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords.
柠檬水配置文件依赖于IMAP、SIVE和邮件提交协议的几个扩展。该文档还定义了一个新的IMAP扩展，并注册了几个新的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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Summary of the Required Support .................................4
3.1. Lemonade Submission Servers ................................4
3.2. Lemonade Message Stores ....................................5
3.3. Lemonade Message Delivery Agents ...........................7
4. Lemonade Submission Servers .....................................7
4.1. Forward without Download ...................................7
4.2. Pipelining .................................................8
4.3. DSN Support ................................................8
4.4. Message Size Declaration ...................................8
4.5. Enhanced Status Code Support ...............................8
4.6. Encryption and Compression .................................8
5. Lemonade Message Stores .........................................9
5.1. Quick Resynchronization ....................................9
5.2. Message Part Handling ......................................9
5.3. Compression ...............................................10
5.4. Notifications .............................................10
5.5. Searching and View Filters ................................12
5.6. Mailbox Handling ..........................................12
5.7. Forward without Download ..................................12
5.8. Additional IMAP Extensions ................................13
5.9. Registration of $Forwarded IMAP Keyword ...................13
5.10. Registration of $SubmitPending and $Submitted
IMAP Keywords ............................................13
5.11. Related IMAP Extensions ..................................14
6. Lemonade Message Delivery Agents ...............................14
7. Lemonade Message User Agents ...................................15
8. Forward without Download .......................................16
8.1. Motivations ...............................................16
8.2. Message Sending Overview ..................................16
8.3. Traditional Strategy ......................................17
8.4. A New Strategy ............................................18
8.5. Security Considerations for Pawn-Tickets ..................27
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Summary of the Required Support .................................4
3.1. Lemonade Submission Servers ................................4
3.2. Lemonade Message Stores ....................................5
3.3. Lemonade Message Delivery Agents ...........................7
4. Lemonade Submission Servers .....................................7
4.1. Forward without Download ...................................7
4.2. Pipelining .................................................8
4.3. DSN Support ................................................8
4.4. Message Size Declaration ...................................8
4.5. Enhanced Status Code Support ...............................8
4.6. Encryption and Compression .................................8
5. Lemonade Message Stores .........................................9
5.1. Quick Resynchronization ....................................9
5.2. Message Part Handling ......................................9
5.3. Compression ...............................................10
5.4. Notifications .............................................10
5.5. Searching and View Filters ................................12
5.6. Mailbox Handling ..........................................12
5.7. Forward without Download ..................................12
5.8. Additional IMAP Extensions ................................13
5.9. Registration of $Forwarded IMAP Keyword ...................13
5.10. Registration of $SubmitPending and $Submitted
IMAP Keywords ............................................13
5.11. Related IMAP Extensions ..................................14
6. Lemonade Message Delivery Agents ...............................14
7. Lemonade Message User Agents ...................................15
8. Forward without Download .......................................16
8.1. Motivations ...............................................16
8.2. Message Sending Overview ..................................16
8.3. Traditional Strategy ......................................17
8.4. A New Strategy ............................................18
8.5. Security Considerations for Pawn-Tickets ..................27
8.6. Copies of Sent Messages: The fcc Problem ..................27
9. Deployment Considerations ......................................28
10. Security Considerations .......................................28
10.1. Confidentiality Protection of Submitted Messages .........28
10.2. TLS ......................................................29
10.3. Additional Extensions and Deployment Models ..............29
11. IANA Considerations ...........................................30
12. Changes since RFC 4550 ........................................30
13. Acknowledgements ..............................................31
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................35
Appendix A. Errata ..............................................37
8.6. Copies of Sent Messages: The fcc Problem ..................27
9. Deployment Considerations ......................................28
10. Security Considerations .......................................28
10.1. Confidentiality Protection of Submitted Messages .........28
10.2. TLS ......................................................29
10.3. Additional Extensions and Deployment Models ..............29
11. IANA Considerations ...........................................30
12. Changes since RFC 4550 ........................................30
13. Acknowledgements ..............................................31
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................35
Appendix A. Errata ..............................................37
The Lemonade Profile, or simply Lemonade, provides enhancements to Internet email to support diverse service environments. Lemonade mail servers provide both a Lemonade Submission Server and a Lemonade Message Store, which are based on the existing [SUBMIT] and [IMAP] protocols, respectively. They MAY also include a Lemonade Message Delivery Agent, which provides delivery-time filtering services based on [SIEVE].
Lemonade配置文件（简称Lemonade）为Internet电子邮件提供了增强功能，以支持不同的服务环境。柠檬水邮件服务器提供柠檬水提交服务器和柠檬水消息存储，分别基于现有的[SUBMIT]和[IMAP]协议。它们还可能包括柠檬水消息传递代理，该代理基于[SIEVE]提供传递时间过滤服务。
This document describes the Lemonade Profile that includes:
本文档介绍了柠檬水概况，包括：
o General common enhancements to Internet Mail, described in 5 and 4.
o Internet邮件的通用增强功能，如5和4所述。
o "Forward without download" that describes exchanges between Lemonade clients and servers to allow submitting new email messages incorporating content that resides on locations external to the client, described in Section 8.
o “转发而不下载”，描述柠檬汁客户端和服务器之间的交换，以允许提交包含驻留在客户端外部位置的内容的新电子邮件，如第8节所述。
o Quick mailbox resynchronization, described in Section 5.1.
o 快速邮箱重新同步，如第5.1节所述。
o Extensions to support more precise, and broader, notifications from the store in support of notifications and view filters, described in 5.4.1 and 5.5.
o 5.4.1和5.5中描述的扩展，用于支持来自存储区的更精确、更广泛的通知，以支持通知和视图过滤器。
o Delivery-time filtering in support of typical mail management use cases, as described in Section 3.3.
o 如第3.3节所述，支持典型邮件管理用例的交付时间筛选。
The LEMONADE WG used the architecture shown in [LEMONADE-ARCH] to develop the Lemonade Profile.
柠檬水工作组使用[LEMONADE-ARCH]中所示的架构来开发柠檬水配置文件。
It is intended that the Lemonade Profile support realizations of the OMA's mobile email enabler (MEM) (see [OMA-MEM-REQ] and [OMA-MEM-ARCH]) using Internet Mail protocols defined by the IETF.
柠檬水配置文件旨在支持使用IETF定义的互联网邮件协议实现OMA的移动电子邮件启用码（MEM）（见[OMA-MEM-REQ]和[OMA-MEM-ARCH]）。
In examples, "M:", "I:", and "S:" indicate lines sent by the client Message User Agent, IMAP email server, and SMTP submit server, respectively.
在示例中，“M:”、“I:”和“S:”分别表示客户端消息用户代理、IMAP电子邮件服务器和SMTP提交服务器发送的行。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Other capitalized words are typically names of extensions or commands -- these are uppercased for clarity only, and are case-insensitive.
其他大写的词通常是扩展名或命令名——它们仅为清晰起见而大写，不区分大小写。
This document uses terminology defined in [RFC5598]. See [RFC5598] for further details on Email Architecture.
本文件使用[RFC5598]中定义的术语。有关电子邮件体系结构的更多详细信息，请参阅[RFC5598]。
All examples in this document are optimized for Lemonade use and might not represent examples of proper protocol usage for a general use Submit/IMAP client. In particular, examples assume that Submit and IMAP servers support all Lemonade extensions described in this document, so they do not demonstrate fallbacks in the absence of an extension.
本文档中的所有示例都针对柠檬水的使用进行了优化，并且可能不代表通用Submit/IMAP客户端的正确协议使用示例。特别是，示例假定Submit和IMAP服务器支持本文档中描述的所有Lemonade扩展，因此它们不会在没有扩展的情况下演示回退。
Lemonade Submission Servers MUST provide a service as described in [SUBMIT], and MUST support the following. Note that the Lemonade Profile imposes further requirements for some cases, detailed in the sections cited.
柠檬汁提交服务器必须提供[SUBMIT]中所述的服务，并且必须支持以下内容。请注意，柠檬水概况对某些情况提出了进一步的要求，详情见所引用的章节。
+---------------------+--------------------+--------------+
| SMTP extension | Reference | Requirements |
+---------------------+--------------------+--------------+
| 8BITMIME | [SMTP-8BITMIME] | [SMTP-BURL] |
| AUTH | [SMTP-AUTH] | [SUBMIT] |
| BINARYMIME | [SMTP-BINARYMIME] | Section 4.1 |
| BURL imap | [SMTP-BURL] | Section 8 |
| CHUNKING | [SMTP-BINARYMIME] | Section 4.1 |
| DSN | [SMTP-DSN] | Section 4.3 |
| ENHANCEDSTATUSCODES | [SMTP-STATUSCODES] | Section 4.5 |
| PIPELINING | [SMTP-PIPELINING] | Section 4.2 |
| SIZE | [SMTP-SIZE] | Section 4.4 |
| STARTTLS | [SMTP-TLS] | Section 4.6 |
+---------------------+--------------------+--------------+
+---------------------+--------------------+--------------+
| SMTP extension | Reference | Requirements |
+---------------------+--------------------+--------------+
| 8BITMIME | [SMTP-8BITMIME] | [SMTP-BURL] |
| AUTH | [SMTP-AUTH] | [SUBMIT] |
| BINARYMIME | [SMTP-BINARYMIME] | Section 4.1 |
| BURL imap | [SMTP-BURL] | Section 8 |
| CHUNKING | [SMTP-BINARYMIME] | Section 4.1 |
| DSN | [SMTP-DSN] | Section 4.3 |
| ENHANCEDSTATUSCODES | [SMTP-STATUSCODES] | Section 4.5 |
| PIPELINING | [SMTP-PIPELINING] | Section 4.2 |
| SIZE | [SMTP-SIZE] | Section 4.4 |
| STARTTLS | [SMTP-TLS] | Section 4.6 |
+---------------------+--------------------+--------------+
Lemonade Message Stores MUST provide a service as described in [IMAP], and MUST support the following. Note that the Lemonade Profile imposes further requirements for some cases, detailed in the sections cited.
柠檬水消息存储必须提供[IMAP]中所述的服务，并且必须支持以下内容。请注意，柠檬水概况对某些情况提出了进一步的要求，详情见所引用的章节。
+------------------------+------------------+---------------+
| IMAP extension | Reference | Requirements |
+------------------------+------------------+---------------+
| BINARY | [IMAP-BINARY] | Section 5.2 |
| CATENATE | [IMAP-CATENATE] | Section 5.7 |
| COMPRESS=DEFLATE | [IMAP-COMPRESS] | Section 5.3 |
| CONDSTORE | [IMAP-CONDSTORE] | Section 5.1 |
| CONTEXT=SEARCH | [IMAP-CONTEXT] | Section 5.5 |
| CONTEXT=SORT | [IMAP-CONTEXT] | Section 5.5 |
| CONVERT | [IMAP-CONVERT] | Section 5.2 |
| ENABLE | [IMAP-ENABLE] | Section 5.1 |
| ESEARCH | [IMAP-ESEARCH] | Section 5.5 |
| ESORT | [IMAP-CONTEXT] | Section 5.5 |
| I18NLEVEL=1 | [IMAP-I18N] | Section 5.8 |
| IDLE | [IMAP-IDLE] | Section 5.4.1 |
| LITERAL+ | [IMAP-LITERAL+] | Section 5.8 |
| NAMESPACE | [IMAP-NAMESPACE] | Section 5.6 |
| NOTIFY | [IMAP-NOTIFY] | Section 5.4.1 |
| QRESYNC | [IMAP-QRESYNC] | Section 5.1 |
| SASL-IR | [IMAP-SASL-IR] | Section 5.8 |
| SORT | [IMAP-SORT] | Section 5.5 |
| STARTTLS | [IMAP] | - |
| UIDPLUS | [IMAP-UIDPLUS] | Section 5.7 |
| URLAUTH | [IMAP-URLAUTH] | Section 5.7 |
| URL-PARTIAL | Section 5.7.1 | Section 5.7 |
| $Forwarded keyword | - | Section 5.9 |
| $SubmitPending keyword | - | Section 5.10 |
| $Submitted keyword | - | Section 5.10 |
+------------------------+------------------+---------------+
+------------------------+------------------+---------------+
| IMAP extension | Reference | Requirements |
+------------------------+------------------+---------------+
| BINARY | [IMAP-BINARY] | Section 5.2 |
| CATENATE | [IMAP-CATENATE] | Section 5.7 |
| COMPRESS=DEFLATE | [IMAP-COMPRESS] | Section 5.3 |
| CONDSTORE | [IMAP-CONDSTORE] | Section 5.1 |
| CONTEXT=SEARCH | [IMAP-CONTEXT] | Section 5.5 |
| CONTEXT=SORT | [IMAP-CONTEXT] | Section 5.5 |
| CONVERT | [IMAP-CONVERT] | Section 5.2 |
| ENABLE | [IMAP-ENABLE] | Section 5.1 |
| ESEARCH | [IMAP-ESEARCH] | Section 5.5 |
| ESORT | [IMAP-CONTEXT] | Section 5.5 |
| I18NLEVEL=1 | [IMAP-I18N] | Section 5.8 |
| IDLE | [IMAP-IDLE] | Section 5.4.1 |
| LITERAL+ | [IMAP-LITERAL+] | Section 5.8 |
| NAMESPACE | [IMAP-NAMESPACE] | Section 5.6 |
| NOTIFY | [IMAP-NOTIFY] | Section 5.4.1 |
| QRESYNC | [IMAP-QRESYNC] | Section 5.1 |
| SASL-IR | [IMAP-SASL-IR] | Section 5.8 |
| SORT | [IMAP-SORT] | Section 5.5 |
| STARTTLS | [IMAP] | - |
| UIDPLUS | [IMAP-UIDPLUS] | Section 5.7 |
| URLAUTH | [IMAP-URLAUTH] | Section 5.7 |
| URL-PARTIAL | Section 5.7.1 | Section 5.7 |
| $Forwarded keyword | - | Section 5.9 |
| $SubmitPending keyword | - | Section 5.10 |
| $Submitted keyword | - | Section 5.10 |
+------------------------+------------------+---------------+
In addition to this list, any Lemonade Message Stores MUST send the CAPABILITY response code (see Section 7.1 of [IMAP]) in the initial server greeting and after the LOGIN/AUTHENTICATE commands.
除此列表外，任何柠檬水消息存储必须在初始服务器问候语和登录/验证命令后发送功能响应代码（参见[IMAP]第7.1节）。
Lemonade Message Delivery Agents MUST support Sieve mail filtering language as described in [SIEVE], and MUST support the following Sieve extensions. Note that the Lemonade Profile imposes further requirements for some cases, detailed in the sections cited.
柠檬水邮件传递代理必须支持[Sieve]中所述的Sieve邮件过滤语言，并且必须支持以下Sieve扩展。请注意，柠檬水概况对某些情况提出了进一步的要求，详情见所引用的章节。
+------------------------------+--------------------+--------------+
| Sieve extension | Reference | Requirements |
+------------------------------+--------------------+--------------+
| ENOTIFY | [SIEVE-NOTIFY] | Section 6 |
| IMAP4FLAGS | [SIEVE-IMAP4FLAGS] | Section 6 |
| RELATIONAL | [SIEVE-RELATIONAL] | Section 6 |
| VACATION | [SIEVE-VACATION] | Section 6 |
| VARIABLES | [SIEVE-VARIABLES] | Section 6 |
| comparator-i;unicode-casemap | [UNICODE-CASEMAP] | Section 6 |
+------------------------------+--------------------+--------------+
+------------------------------+--------------------+--------------+
| Sieve extension | Reference | Requirements |
+------------------------------+--------------------+--------------+
| ENOTIFY | [SIEVE-NOTIFY] | Section 6 |
| IMAP4FLAGS | [SIEVE-IMAP4FLAGS] | Section 6 |
| RELATIONAL | [SIEVE-RELATIONAL] | Section 6 |
| VACATION | [SIEVE-VACATION] | Section 6 |
| VARIABLES | [SIEVE-VARIABLES] | Section 6 |
| comparator-i;unicode-casemap | [UNICODE-CASEMAP] | Section 6 |
+------------------------------+--------------------+--------------+
Lemonade Message Delivery Agents should also consider supporting a Sieve script management protocol, such as [MANAGESIEVE].
柠檬水消息传递代理还应该考虑支持筛选器脚本管理协议，如[MaunsEff]。
All Lemonade Submission Servers implement the Mail Submission protocol described in [SUBMIT], which is in turn a specific profile of [ESMTP]. Therefore, any MUA designed to submit email via [SUBMIT] or [ESMTP] will interoperate with Lemonade Submission Servers.
所有Lemonade提交服务器都实现[SUBMIT]中描述的邮件提交协议，这是[ESMTP]的特定配置文件。因此，任何旨在通过[submit]或[ESMTP]提交电子邮件的MUA都将与柠檬水提交服务器进行互操作。
In addition, Lemonade Submission Servers implement the following set of SMTP and Submission extensions to increase message submission efficiency.
此外，Lemonade提交服务器实现了以下一组SMTP和提交扩展，以提高邮件提交效率。
In order to optimize network usage for the typical case where message content is copied to, or sourced from, the IMAP store, Lemonade provides support for a suite of extensions collectively known as "forward without download", discussed in detail in Section 8.
为了优化消息内容复制到IMAP商店或来源于IMAP商店的典型情况下的网络使用，Lemonade提供了一套扩展的支持，统称为“无下载转发”，详细讨论见第8节。
Lemonade Submission Servers MUST support BURL [SMTP-BURL], 8BITMIME [SMTP-8BITMIME], BINARYMIME [SMTP-BINARYMIME], and CHUNKING [SMTP-BINARYMIME] SMTP extensions.
柠檬汁提交服务器必须支持BURL[SMTP-BURL]、8BITMIME[SMTP-8BITMIME]、BINARYMIME[SMTP-BINARYMIME]和分块[SMTP-BINARYMIME]SMTP扩展。
BURL MUST support URLAUTH type URLs [IMAP-URLAUTH], and thus MUST advertise the "imap" option following the BURL EHLO keyword (see [SMTP-BURL] for more details).
BURL必须支持URLAUTH类型的URL[IMAP-URLAUTH]，因此必须在BURL EHLO关键字后公布“IMAP”选项（有关详细信息，请参阅[SMTP-BURL]）。
Some clients regularly use networks with a relatively high latency, such as mobile or satellite-based networks. Avoidance of round trips within a transaction has a great advantage for the reduction in both bandwidth and total transaction time. For this reason, Lemonade-compliant mail Submission Servers MUST support the SMTP service extensions for command pipelining [SMTP-PIPELINING].
一些客户端经常使用延迟相对较高的网络，如移动或基于卫星的网络。避免事务中的往返对于减少带宽和总事务时间有很大的好处。因此，与柠檬水兼容的邮件提交服务器必须支持SMTP服务扩展以进行命令管道[SMTP-pipelining]。
Lemonade-compliant mail Submission Servers MUST support SMTP service extensions for delivery status notifications [SMTP-DSN].
Lemonade兼容的邮件提交服务器必须支持用于传递状态通知的SMTP服务扩展[SMTP-DSN]。
There is a distinct advantage in detecting failure cases as early as possible in many cases, such as where the user is charged per octet, or where bandwidth is low. This is especially true of large message sizes.
在许多情况下，尽早检测故障情况具有明显的优势，例如用户按八位字节计费，或者带宽较低。对于较大的消息大小尤其如此。
Lemonade Submission Servers MUST support the SMTP service extension for message size declaration [SMTP-SIZE].
Lemonade提交服务器必须支持邮件大小声明[SMTP-size]的SMTP服务扩展。
Lemonade Submission Servers MUST expand all BURL parts before evaluating if the supplied message size is acceptable.
Lemonade提交服务器必须在评估提供的消息大小是否可接受之前扩展所有BURL部分。
A Lemonade-capable client SHOULD use message size declaration. In particular, the client MUST NOT send a message to a mail Submission Server if it knows that the message exceeds the maximal message size advertised by the Submission Server. When including a message size in the MAIL FROM command, the client MUST use a value that is at least as large as the size of the assembled message data after resolution of all BURL parts.
支持柠檬水的客户端应该使用消息大小声明。特别是，如果客户机知道消息超过提交服务器公布的最大消息大小，则不得向邮件提交服务器发送消息。在MAIL FROM命令中包含消息大小时，客户端必须使用一个值，该值至少与解析所有BURL部分后组合的消息数据的大小相同。
Lemonade-compliant mail Submission Servers MUST support the SMTP service extension for returning enhanced error codes [SMTP-STATUSCODES]. These allow a client to determine the precise cause of failure.
Lemonade兼容的邮件提交服务器必须支持SMTP服务扩展以返回增强的错误代码[SMTP-STATUSCODES]。这些允许客户端确定故障的确切原因。
Lemonade-compliant mail Submission Servers MUST support the SMTP service extension for secure SMTP over Transport Layer Security (TLS) [SMTP-TLS].
Lemonade兼容的邮件提交服务器必须支持SMTP服务扩展，以实现安全的SMTP over Transport Layer Security（TLS）[SMTP-TLS]。
Support for the DEFLATE compression method, as described in [TLS-COMP], is RECOMMENDED.
建议支持[TLS-COMP]中所述的放气压缩方法。
All Lemonade Message Stores implement the Internet Message Access Protocol, as defined in [IMAP]. Therefore, any MUA written to access messages using the facilities described in [IMAP] will interoperate with a Lemonade Message Store.
所有柠檬水消息存储都实现了[IMAP]中定义的互联网消息访问协议。因此，任何使用[IMAP]中描述的设施来访问消息的MUA都将与柠檬汁消息存储互操作。
In addition, Lemonade Message Stores provide a set of extensions to address the limitations of some clients and networks.
此外，Lemonade消息存储提供了一组扩展来解决某些客户端和网络的限制。
Resynchronization is a costly part of an IMAP session, and mobile networks are generally more prone to unintended disconnection, which in turn makes this problem more acute. Therefore, Lemonade Message Stores provide a suite of extensions to reduce the synchronization cost.
重新同步是IMAP会话中代价高昂的一部分，移动网络通常更容易发生意外断开，这反过来又使这个问题更加严重。因此，Lemonade消息存储提供了一套扩展来降低同步成本。
Lemonade-compliant IMAP servers MUST support the CONDSTORE [IMAP-CONDSTORE], the QRESYNC [IMAP-QRESYNC], and the ENABLE [IMAP-ENABLE] extensions. These allow a client to quickly resynchronize any mailbox by asking the server to return all flag changes and expunges that have occurred since a previously recorded state. This can also speed up client reconnect in case the transport layer is cut, whether accidentally or as part of a change in network.
柠檬水兼容的IMAP服务器必须支持CONDSTORE[IMAP-CONDSTORE]、QRESYNC[IMAP-QRESYNC]和ENABLE[IMAP-ENABLE]扩展。这些允许客户端通过请求服务器返回自先前记录状态以来发生的所有标志更改和删除，快速重新同步任何邮箱。这还可以在传输层被切断的情况下加速客户端重新连接，无论是意外切断还是作为网络更改的一部分。
When implementing QRESYNC [IMAP-QRESYNC], client and servers need to also comply with errata submitted for this document (see Appendix A).
在实施QRESYNC[IMAP-QRESYNC]时，客户端和服务器还需要遵守为本文档提交的勘误表（见附录A）。
[IMAP-SYNC-HOWTO] details how clients perform efficient mailbox resynchronization.
[IMAP-SYNC-HOWTO]详细说明客户端如何执行有效的邮箱重新同步。
The handling of message parts, especially attachments, represents a set of challenges to limited devices, both in terms of the bandwidth used and the capability of the device.
消息部分（尤其是附件）的处理对有限的设备来说是一系列挑战，包括使用的带宽和设备的能力。
Lemonade-compliant IMAP servers MUST support the BINARY [IMAP-BINARY] extension. This moves MIME body part decoding operations from the client to the server. The decoded data is equal to or less in size than the encoded representation, so this reduces bandwidth effectively.
Lemonade兼容的IMAP服务器必须支持二进制[IMAP-BINARY]扩展。这将MIME正文部分解码操作从客户端移动到服务器。解码数据的大小等于或小于编码表示，因此这有效地减少了带宽。
[IMAP-BINARY] allows for servers to refuse to accept uploaded messages containing binary data, by not accepting the Binary content-transfer-encoding; however, Lemonade-compliant IMAP servers SHALL always accept binary encoded MIME messages in APPEND commands for any folder.
[IMAP-BINARY]允许服务器通过不接受二进制内容传输编码来拒绝接受包含二进制数据的上传消息；但是，符合Lemonade的IMAP服务器应始终在任何文件夹的APPEND命令中接受二进制编码的MIME消息。
[IMAP-CONVERT] MUST also be supported by servers, which allows clients to request conversions between media types, and allows for scaling images, etc. This provides the ability to view attachments (and sometimes body parts) without the facility to cope with a wide range of media types, or to efficiently view attachments.
[IMAP-CONVERT]还必须由服务器支持，这允许客户端请求媒体类型之间的转换，并允许缩放图像等。这提供了查看附件（有时是身体部位）的能力，而不需要处理各种媒体类型的设备，也可以高效地查看附件。
Lemonade Message Stores SHOULD support the Deflate compression algorithm for TLS, as defined in [TLS-COMP], in order to facilitate compression at as low a level as possible.
柠檬水消息存储应支持TLS的Deflate压缩算法，如[TLS-COMP]中所定义，以便在尽可能低的级别上进行压缩。
However, the working group acknowledges that for many endpoints, this is a rarely deployed technology, and as such, Lemonade Message Stores MUST provide [IMAP-COMPRESS] support for fallback application-level stream compression, where TLS is not actively providing compression.
然而，工作组承认，对于许多端点来说，这是一种很少部署的技术，因此，Lemonade消息存储必须为回退应用程序级流压缩提供[IMAP-COMPRESS]支持，而TLS并不主动提供压缩。
The addition of server-to-client notifications transforms the Lemonade Profile into an event-based synchronization protocol. Whenever an event occurs that interests the MUA, a notification can be generated. The Lemonade WG used the notifications architecture shown in [LEMONADE-NOTIFICATIONS] to develop the Lemonade Profile.
服务器到客户端通知的添加将柠檬水配置文件转换为基于事件的同步协议。每当MUA感兴趣的事件发生时，都会生成通知。柠檬水工作组使用[Lemonade-notifications]中所示的通知体系结构来开发柠檬水配置文件。
If the MUA is connected to the IMAP server, inband notifications are generated using the facilities outlined in Section 5.4.1.
如果MUA连接到IMAP服务器，则使用第5.4.1节中概述的设施生成带内通知。
When the MUA is not connected, the notification filter generates an outband notification. The notification filter may be considered as acting on a push email repository.
当MUA未连接时，通知过滤器将生成带外通知。通知过滤器可被视为作用于推送电子邮件存储库。
If the MUA is not connected, and outband notification is disabled, the client must perform a quick-sync on reconnect to determine mailbox changes, using the mechanisms outlined in Section 5.1.
如果未连接MUA，并且禁用带外通知，则客户端必须使用第5.1节中概述的机制在重新连接时执行快速同步，以确定邮箱更改。
Lemonade Message Stores MUST support the IDLE [IMAP-IDLE] extension. The extension allows clients to receive unsolicited notifications about changes in the selected mailbox, without needing to poll for changes. The responses forming these notifications MUST be sent in a timely manner when such changes happen.
Lemonade消息存储必须支持IDLE[IMAP-IDLE]扩展。扩展允许客户端接收有关所选邮箱中更改的未经请求的通知，而无需轮询更改。当发生此类变更时，必须及时发送构成这些通知的响应。
Lemonade Message Stores also provide the NOTIFY extension described in [IMAP-NOTIFY], which allows clients to request specific event types to be sent immediately to the client, both for the currently selected folder and others. Such event types include message delivery and mailbox renames.
Lemonade消息存储还提供了[IMAP-NOTIFY]中所述的NOTIFY扩展，它允许客户端请求将当前选定文件夹和其他文件夹的特定事件类型立即发送到客户端。此类事件类型包括邮件传递和邮箱重命名。
Lemonade and TCP provide for long-lived idle connections between the client and mail store, allowing the server to push notifications within IMAP. Some mobile networks support dormancy, which shuts down the radio traffic channel during idle periods to conserve handset and network resources, while maintaining IP and TCP state. (See the [LEMONADE-DEPLOYMENTS] document for more information.)
Lemonade和TCP在客户端和邮件存储之间提供了长期的空闲连接，允许服务器在IMAP中推送通知。一些移动网络支持休眠，即在空闲期间关闭无线通信信道以节省手机和网络资源，同时保持IP和TCP状态。（有关更多信息，请参阅[LEMONADE-DEPLOYMENTS]文档。）
However, there are environments where the email client cannot remain active indefinitely, or where it is not advisable (or even always possible) for TCP connections to the server to remain up while idle for extended periods. In these situations, a good user experience requires that when "interesting" events occur in the mail store, the client be informed so that it can connect and resynchronize. At an absolute minimum, this requires that at least the arrival of new mail generate some sort of wake-up to the email client. A number of vendors have implemented various solutions to this. As examples of what has been done, for many years (long pre-dating cellular handsets) the technique described in [FINGER-HACK] has been supported. Today, a number of email vendors include facilities to send SMS or other simple non-stream messages to clients on handsets when new mail arrives. The Open Mobile Alliance (OMA) has published a mechanism that uses WAP PUSH to send a basic message containing a URL [OMA-EMN]. The IETF is investigating ways to standardize enhanced functionality in this area.
但是，在某些环境中，电子邮件客户端不能无限期地保持活动状态，或者不建议（甚至不总是可能）到服务器的TCP连接在长时间空闲时保持打开状态。在这些情况下，良好的用户体验要求在邮件存储中发生“有趣的”事件时通知客户机，以便它能够连接并重新同步。至少，这要求至少在新邮件到达时对电子邮件客户端产生某种唤醒。许多供应商已经为此实施了各种解决方案。作为已经完成的工作的例子，多年来（早在手机过时之前），在[FINGER-HACK]中描述的技术一直得到支持。如今，许多电子邮件供应商提供了在新邮件到达时通过手机向客户端发送SMS或其他简单的非流式消息的设施。开放移动联盟（OMA）发布了一种机制，使用WAP推送发送包含URL[OMA-EMN]的基本消息。IETF正在研究该领域增强功能的标准化方法。
A "push email" user experience can be achieved using any number of techniques, ranging from always-on TCP connectivity to the server and the NOTIFY extension described above, to OMA EMN, or even a non-standard trigger message over SMS. In any technique, the client learns of the existence of new mail, and decides to fetch information about it, some part of it, or all of it, and then presents this to the user.
“推送电子邮件”用户体验可以使用多种技术实现，从与服务器和上述NOTIFY扩展的始终在线TCP连接，到OMA EMN，甚至是通过SMS的非标准触发消息。在任何技术中，客户机都会知道新邮件的存在，并决定获取关于它的信息、部分信息或全部信息，然后将其呈现给用户。
Lemonade Message Stores MUST support the ESEARCH [IMAP-ESEARCH] extension. The extension allows clients to efficiently find the first or last messages, find a count of matching messages, and obtain a list of matching messages in a considerably more compact representation.
柠檬水邮件存储必须支持ESEARCH[IMAP-ESEARCH]扩展。该扩展允许客户端高效地查找第一条或最后一条消息，查找匹配消息的计数，并以相当紧凑的表示形式获取匹配消息的列表。
Lemonade Message Stores also provide a mechanism for clients to avoid handling an entire mailbox, instead accessing a view of the mailbox. This technique, common in many desktop clients as a client-side capability, is useful for constrained clients to minimize the quantity of messages and notification data.
Lemonade邮件存储还为客户端提供了一种机制，以避免处理整个邮箱，而不是访问邮箱的视图。这种技术作为客户端功能在许多桌面客户端中很常见，对于受约束的客户端来说非常有用，可以最大限度地减少消息和通知数据的数量。
Lemonade Message Stores therefore MUST implement the CONTEXT=SEARCH, ESORT, and CONTEXT=SORT extensions defined in [IMAP-CONTEXT], as well as the SORT extension defined in [IMAP-SORT].
因此，Lemonade消息存储必须实现[IMAP-CONTEXT]中定义的CONTEXT=SEARCH、ESORT和CONTEXT=SORT扩展，以及[IMAP-SORT]中定义的排序扩展。
Lemonade Message Stores MUST support the NAMESPACE [IMAP-NAMESPACE] extension. The extension allows clients to discover shared mailboxes and mailboxes belonging to other users, and provide a normalized hierarchy view of the mailboxes available.
Lemonade消息存储必须支持命名空间[IMAP-NAMESPACE]扩展。该扩展允许客户端发现共享邮箱和属于其他用户的邮箱，并提供可用邮箱的规范化层次结构视图。
Lemonade Message Stores MUST support the I18NLEVEL=<n> [IMAP-I18N] extension, with <n> having the value 1 or 2. It adds support for non-English (internationalized) search and sort functions. (Note that I18NLEVEL=2 implies support for I18NLEVEL=1, so a Lemonade-compliant client that makes use of this extension MUST recognize either one.)
Lemonade消息存储必须支持I18NLEVEL=<n>[IMAP-I18N]扩展，<n>的值为1或2。它增加了对非英语（国际化）搜索和排序功能的支持。（请注意，I18NLEVEL=2意味着支持I18NLEVEL=1，因此使用此扩展的柠檬水兼容客户端必须识别其中一个。）
In order to optimize network usage for the typical case where message content is copied to, or sourced from, the IMAP store, Lemonade provides support for a suite of extensions collectively known as "forward without download", discussed in detail in Section 8.
为了优化消息内容复制到IMAP商店或来源于IMAP商店的典型情况下的网络使用，Lemonade提供了一套扩展的支持，统称为“无下载转发”，详细讨论见第8节。
Lemonade Message Stores MUST support CATENATE [IMAP-CATENATE], UIDPLUS [IMAP-UIDPLUS], and URLAUTH [IMAP-URLAUTH]. Lemonade Message Stores MUST also support URL-PARTIAL as described in Section 5.7.1.
柠檬汁消息存储必须支持CATENATE[IMAP-CATENATE]、UIDPLUS[IMAP-UIDPLUS]和URLAUTH[IMAP-URLAUTH]。柠檬水消息存储还必须支持第5.7.1节中所述的URL-PARTIAL。
[IMAP-URL] introduced a new syntactic element for referencing a byte range of a message/body part. This is done using the ;PARTIAL= field. If an IMAP server supports PARTIAL in IMAP URL used in
[IMAP-URL]引入了一个新的语法元素，用于引用消息/正文部分的字节范围。这是通过使用；部分=字段。如果IMAP服务器支持中使用的部分IMAP URL
CATENATE and URLAUTH extensions, then it MUST advertise the URL-PARTIAL capability in both the CAPABILITY response and the equivalent response-code.
CATENATE和URLAUTH扩展，则它必须在功能响应和等效响应代码中公布URL-PARTIAL功能。
Lemonade Message Stores MUST support the LITERAL+ [IMAP-LITERAL+] extension. The extension allows clients to save a round trip each time a non-synchronizing literal is sent.
Lemonade消息存储必须支持LITERAL+[IMAP-LITERAL+]扩展。该扩展允许客户端在每次发送非同步文本时保存一次往返。
Lemonade Message Stores MUST also implement the SASL-IR [IMAP-SASL-IR] extension, which allows clients to save a round trip during authentication, potentially pipelining the entire authentication sequence.
Lemonade消息存储还必须实现SASL-IR[IMAP-SASL-IR]扩展，该扩展允许客户端在身份验证过程中节省一次往返，从而可能通过管道传输整个身份验证序列。
Lemonade-compliant IMAP servers MUST support IMAP over TLS [IMAP] as required by [IMAP]. As noted above in Section 5.3, servers SHOULD support the deflate compression algorithm for TLS, as specified in [TLS-COMP].
柠檬水兼容的IMAP服务器必须按照[IMAP]的要求支持TLS[IMAP]上的IMAP。如上文第5.3节所述，服务器应支持[TLS-COMP]中规定的TLS放气压缩算法。
The $Forwarded IMAP keyword is used by several IMAP clients to specify that the marked message was forwarded to another email address, embedded within or attached to a new message. A mail client sets this keyword when it successfully forwards the message to another email address. Typical usage of this keyword is to show a different (or additional) icon for a message that has been forwarded. Once set, the flag SHOULD NOT be cleared.
多个IMAP客户端使用$Forwarded IMAP关键字来指定标记的邮件已转发到另一个电子邮件地址，嵌入或附加到新邮件中。邮件客户端在成功将邮件转发到其他电子邮件地址时设置此关键字。此关键字的典型用法是为已转发的邮件显示不同（或附加）图标。设置后，不应清除该标志。
Lemonade Message Stores MUST be able to store the $Forwarded keyword. They MUST preserve it on the COPY operation. The servers MUST support the SEARCH KEYWORD $Forwarded.
柠檬水消息存储必须能够存储$Forwarded关键字。他们必须在复制操作中保留它。服务器必须支持搜索关键字$Forwarded。
The $SubmitPending IMAP keyword designates the message as awaiting to be submitted. This keyword allows storing messages waiting to be submitted in the same mailbox where messages that were already submitted and/or are being edited are stored. A mail client sets this keyword when it decides that the message needs to be sent out. When a client (it might be a different client from the one that decided that the message is pending submission) starts sending the message, it atomically (using "STORE (UNCHANGEDSINCE)") adds the $Submitted keyword. Once submission is successful, the $SubmitPending keyword is atomically cleared. The two keywords allow messages being actively submitted (messages that have both $Submitted and $SubmitPending keywords set) to be distinguished from messages
$SubmitPending IMAP关键字将消息指定为等待提交。此关键字允许在存储已提交和/或正在编辑的邮件的同一邮箱中存储等待提交的邮件。邮件客户端在决定需要发送邮件时设置此关键字。当一个客户机（可能是另一个客户机，该客户机决定消息正在等待提交）开始发送消息时，它会自动（使用“STORE（UNCHANGEDSINCE）”）添加$Submitted关键字。提交成功后，$SubmitPending关键字将自动清除。这两个关键字允许将活动提交的邮件（同时设置了$Submited和$SubmitPending关键字的邮件）与邮件区分开来
awaiting to be submitted, or from messages already submitted. They also allow all messages that were supposed to be submitted to be found, if the client submitting them crashes or quits before submitting them.
等待提交，或来自已提交的邮件。如果提交消息的客户端崩溃或在提交之前退出，它们还允许找到所有应该提交的消息。
Lemonade Message Stores MUST be able to store the $SubmitPending and the $Submitted keyword. Lemonade Message Stores MUST preserve them on the COPY operation. The servers MUST support the SEARCH KEYWORD $SubmitPending and SEARCH KEYWORD $Submitted.
柠檬水消息存储必须能够存储$SubmitPending和$Submitted关键字。柠檬水消息存储必须在复制操作中保留它们。服务器必须支持搜索关键字$SubmitPending和搜索关键字$Submitted。
Section 5.11 is non-normative.
第5.11节是非规范性的。
Server implementations targeting to fulfill OMA MEM requirements [OMA-MEM-REQ] should consider implementing the [IMAP-FILTERS], which provides a way to persist definition of virtual mailboxes on the server. They should also consider implementing the METADATA-SERVER [METADATA] extension, which provides a way of storing user-defined data associated with a user account.
旨在实现OMA MEM要求的服务器实现[OMA-MEM－Req]应该考虑实现[IMAP-过滤器]，它提供了一种在服务器上持久定义虚拟邮箱的方法。他们还应该考虑实现Meta DATA Server [元数据]扩展，它提供了一种存储与用户帐户相关联的用户定义数据的方法。
Lemonade Message Delivery Agents MUST support the [SIEVE] filtering language at the point of delivery, allowing the user to control which messages are accepted, and where they are filed.
Lemonade消息传递代理必须在传递点支持[SIEVE]过滤语言，允许用户控制接受哪些消息以及在哪里归档。
Lemonade Message Delivery Agents MUST support the Sieve Vacation extension [SIEVE-VACATION], which allows the client to set up an auto-responder, typically to report being on vacation (thus the name of the Sieve extension).
Lemonade消息传递代理必须支持Sieve-Vacation扩展[Sieve-Vacation]，它允许客户端设置自动响应程序，通常报告正在休假（因此是Sieve扩展的名称）。
Lemonade Message Delivery Agents MUST support the Sieve Enotify extension [SIEVE-NOTIFY], which allows a Sieve script to generate notifications (such as XMPP, SIP, or email) about received messages.
Lemonade消息传递代理必须支持Sieve-Enotify扩展[Sieve-NOTIFY]，该扩展允许Sieve脚本生成有关接收消息的通知（如XMPP、SIP或电子邮件）。
Lemonade Message Delivery Agents MUST support the Sieve Variables extension [SIEVE-VARIABLES], which adds support for variables to the Sieve scripting language. This extension is typically used with Sieve Enotify or Vacation to customize responses/notifications.
Lemonade消息传递代理必须支持Sieve变量扩展[Sieve-Variables]，该扩展将变量支持添加到Sieve脚本语言中。此扩展通常与Sieve Enotify或Vacation一起使用，以自定义响应/通知。
Lemonade Message Delivery Agents MUST support the Sieve Relational extension [SIEVE-RELATIONAL], which adds support for relational comparisons to the Sieve scripting language. This extension is typically used together with Sieve Enotify.
Lemonade消息传递代理必须支持Sieve关系扩展[Sieve-Relational]，它为Sieve脚本语言添加了对关系比较的支持。该延伸段通常与筛网Enotify一起使用。
Lemonade Message Delivery Agents MUST support the Sieve Imap4Flags extension [SIEVE-IMAP4FLAGS], which allows a Sieve script to set IMAP flags/keywords when delivering a message to a mailbox. For example, this can be used to automatically mark certain messages as interesting, urgent, etc.
Lemonade邮件传递代理必须支持Sieve Imap4Flags扩展[Sieve-Imap4Flags]，它允许Sieve脚本在将邮件传递到邮箱时设置IMAP标志/关键字。例如，这可以用来自动将某些消息标记为有趣、紧急等。
Lemonade Message Delivery Agents MUST support the i;unicode-casemap comparator in Sieve [UNICODE-CASEMAP], which is declared as "comparator-i;unicode-casemap" in the Sieve "require" statement. The comparator allows for case-insensitive matching of Unicode characters.
柠檬水消息传递代理必须支持i；Sieve[unicode-casemap]中的unicode casemap比较器，在Sieve“require”语句中声明为“comparator-i；unicode casemap”。比较器允许Unicode字符不区分大小写的匹配。
Lemonade Message Delivery Agents should consider supporting Sieve script management using the [MANAGESIEVE] protocol. If they do, they MUST also advertise in [MANAGESIEVE] all Sieve extensions listed in this section.
柠檬水消息传递代理应该考虑使用[MaunsSeave]协议支持筛选器脚本管理。如果他们这样做，他们还必须在[MANAGESIEVE]中公布本节中列出的所有筛扩展。
Although all existing IMAP MUAs are Lemonade compliant in as much as all Lemonade services are based on the existing [IMAP] and [SUBMIT] protocols, client implementors are encouraged to take full advantage of the facilities provided by Lemonade Submission Servers and Lemonade Message Stores, as described in 4 and 5, respectively.
尽管所有现有的IMAP MUA都是柠檬水兼容的，因为所有柠檬水服务都基于现有的[IMAP]和[SUBMIT]协议，但鼓励客户机实现者充分利用柠檬水提交服务器和柠檬水消息存储提供的设施，分别如第4和第5节所述。
When opening a connection to the Submission Server, clients MUST do so using port 587 unless explicitly configured to use an alternate port [RFC5068]. (Note that this requirement is somewhat stronger than the one specified in [SUBMIT], as [SUBMIT] didn't prescribe the exact procedure to be used by submission clients.) If the TCP connection to the submission server fails to open using port 587, the client MAY then immediately retry using a different port, such as 25. See [SUBMIT] for information on why using port 25 is likely to fail depending on the current location of the client, and may result in a failure code during the SMTP transaction.
打开与提交服务器的连接时，客户端必须使用端口587，除非明确配置为使用备用端口[RFC5068]。（请注意，此要求比[SUBMIT]中指定的要求稍强，因为[SUBMIT]没有规定提交客户端使用的确切程序。）如果使用端口587无法打开到提交服务器的TCP连接，则客户端可以立即使用其他端口（如25）重试。请参阅[SUBMIT]，了解使用端口25可能失败的原因，具体取决于客户端的当前位置，并可能导致SMTP事务期间出现故障代码。
In addition, some specifications are useful to support interoperable messaging with an enhanced user experience.
此外，一些规范对于支持具有增强用户体验的互操作消息传递非常有用。
Lemonade-capable clients SHOULD support the Format and DelSp parameters to the text/plain media type described in [FLOWED], and generate this format for messages.
支持柠檬水的客户端应支持[FLOWED]中描述的文本/普通媒体类型的格式和DelSp参数，并为消息生成此格式。
Lemonade-capable clients SHOULD support, and use, the $Forwarded keyword described in Section 5.9.
有柠檬水功能的客户端应该支持并使用第5.9节中描述的$Forwarded关键字。
The advent of client/server email using the [IMAP] and [SUBMIT] protocols changed what formerly were local disk operations to become repetitive network data transmissions.
使用[IMAP]和[SUBMIT]协议的客户机/服务器电子邮件的出现改变了以前的本地磁盘操作，变成了重复的网络数据传输。
Lemonade "forward without download" makes use of the [SMTP-BURL] extension to enable access to external sources during the submission of a message. In combination with the [IMAP-URLAUTH] extension, inclusion of message parts or even entire messages from the IMAP mail store is possible with a minimal trust relationship between the IMAP and SMTP SUBMIT servers.
Lemonade“转发而不下载”利用[SMTP-BURL]扩展在提交邮件期间允许访问外部源。与[IMAP-URLAUTH]扩展相结合，IMAP邮件存储区中的邮件部分甚至整个邮件都可以包含，IMAP和SMTP提交服务器之间的信任关系最小。
Lemonade "forward without download" has the advantage of maintaining one submission protocol, and thus avoids the risk of having multiple parallel and possibly divergent mechanisms for submission. The client can use [SUBMIT] extensions without these being added to IMAP. Furthermore, by keeping the details of message submission in the SMTP SUBMIT server, Lemonade "forward without download" can work with other message retrieval protocols such as POP, NNTP, or whatever else may be designed in the future.
Lemonade“无下载转发”的优点是维护一个提交协议，从而避免了使用多个并行且可能不同的提交机制的风险。客户端可以使用[SUBMIT]扩展，而无需将这些扩展添加到IMAP。此外，通过将邮件提交的详细信息保存在SMTP提交服务器中，Lemonade“无下载转发”可以与其他邮件检索协议（如POP、NNTP或将来可能设计的任何其他协议）配合使用。
The act of sending an email message can be thought of as involving multiple steps: initiation of a new draft, draft editing, message assembly, and message submission.
发送电子邮件的行为可以被认为涉及多个步骤：启动新草稿、草稿编辑、消息汇编和消息提交。
Initiation of a new draft and draft editing takes place in the MUA. Frequently, users choose to save more complex messages on an [IMAP] server (via the APPEND command with the \Draft flag) for later recall by the MUA and resumption of the editing process.
新草案的启动和草案编辑在MUA进行。通常，用户选择将更复杂的消息保存在[IMAP]服务器上（通过带有\Draft标志的APPEND命令），以便MUA稍后调用并恢复编辑过程。
Message assembly is the process of producing a complete message from the final revision of the draft and external sources. At assembly time, external data is retrieved and inserted in the message.
消息组装是从草稿和外部源的最终版本生成完整消息的过程。在汇编时，检索外部数据并将其插入到消息中。
Message submission is the process of inserting the assembled message into the [ESMTP] infrastructure, typically using the [SUBMIT] protocol.
消息提交是将组装好的消息插入[ESMTP]基础设施的过程，通常使用[SUBMIT]协议。
Traditionally, messages are initiated, edited, and assembled entirely within an MUA, although drafts may be saved to an [IMAP] server and later retrieved from the server. The completed text is then transmitted to a Message Submission Agent (MSA) for delivery.
传统上，消息完全在MUA中启动、编辑和组装，尽管草稿可能保存到[IMAP]服务器，然后从服务器检索。然后将完成的文本传输到消息提交代理（MSA）进行交付。
There is often no clear boundary between the editing and assembly processes. If a message is forwarded, its content is often retrieved immediately and inserted into the message text. Similarly, when external content is inserted or attached, the content is usually retrieved immediately and made part of the draft.
编辑和装配过程之间通常没有明确的界限。如果消息被转发，通常会立即检索其内容并插入到消息文本中。类似地，当插入或附加外部内容时，通常会立即检索内容并使其成为草稿的一部分。
As a consequence, each save of a draft and subsequent retrieval of the draft transmits that entire (possibly large) content, as does message submission.
因此，草稿的每次保存和随后的草稿检索都会传输整个（可能很大）内容，消息提交也是如此。
In the past, this was not much of a problem, because drafts, external data, and the message submission mechanism were typically located on the same system as the MUA. The most common problem was running out of disk quota.
在过去，这不是什么大问题，因为草稿、外部数据和消息提交机制通常与MUA位于同一个系统上。最常见的问题是磁盘配额不足。
The model distinguishes between a Message User Agent (MUA), an IMAPv4Rev1 Server ([IMAP]), and an SMTP submit server ([SUBMIT]), as illustrated in Figure 1.
该模型区分了消息用户代理（MUA）、IMAPv4Rev1服务器（[IMAP]）和SMTP提交服务器（[submit]），如图1所示。
+--------------------+ +--------------+
| | <------------ | |
| MUA (M) | | IMAPv4Rev1 |
| | | Server |
| | ------------> | (Server I) |
+--------------------+ +--------------+
^ | ^ |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | v
| | +--------------+
| |----------------------> | SMTP |
| | Submit |
|-----------------------------| Server |
| (Server S) |
+--------------+
+--------------------+ +--------------+
| | <------------ | |
| MUA (M) | | IMAPv4Rev1 |
| | | Server |
| | ------------> | (Server I) |
+--------------------+ +--------------+
^ | ^ |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | v
| | +--------------+
| |----------------------> | SMTP |
| | Submit |
|-----------------------------| Server |
| (Server S) |
+--------------+
Figure 1: Lemonade "forward without download"
图1：柠檬水“无需下载即可转发”
Lemonade "forward without download" allows a Message User Agent to compose and forward an email combining fragments that are located in an IMAP server, without having to download these fragments to the client.
Lemonade“forward without download”允许消息用户代理编写并转发一封电子邮件，该电子邮件结合了位于IMAP服务器中的片段，而无需将这些片段下载到客户端。
This section informatively describes two ways to perform "forward without download" based on where the message assembly takes place. The first uses the extended APPEND command [IMAP-CATENATE] to edit a draft message in the message store and cause the message assembly on the IMAP server. This is most often used when a copy of the message is to be retained on the IMAP server, as discussed in Section 8.6.
本节根据消息组装发生的位置，详细描述了执行“转发而不下载”的两种方法。第一种方法使用扩展的APPEND命令[IMAP-CATENATE]编辑消息存储中的草稿消息，并在IMAP服务器上生成消息程序集。如第8.6节所述，当消息副本保留在IMAP服务器上时，最常用此选项。
The second uses a succession of BURL and BDAT commands to submit and assemble through concatenation, message data from the client and external data fetched from the provided URL. The two subsequent sections provide step-by-step instructions on how "forward without download" is achieved.
第二种方法使用一系列BURL和BDAT命令，通过连接、来自客户端的消息数据和从提供的URL获取的外部数据来提交和组装。接下来的两个部分提供了如何实现“无下载转发”的分步说明。
In the [SMTP-BURL]/[IMAP-CATENATE] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. The [IMAP-CATENATE] extension to [IMAP] is then used to create the messages on the IMAP server by transmitting new text and assembling them. The UIDPLUS [IMAP-UIDPLUS] IMAP extension is used by the client in order to learn the UID of the created messages. Finally, an [IMAP-URLAUTH] format URL is given to a [SUBMIT] server for submission using the BURL [SMTP-BURL] extension.
在柠檬水“无下载转发”策略的[SMTP-BURL]/[IMAP-CATENATE]变体中，消息最初是在MUA中合成和编辑的。然后使用[IMAP]的[IMAP-CATENATE]扩展在IMAP服务器上创建消息，方法是传输新文本并将其组合。客户端使用UIDPLUS[IMAP-UIDPLUS]IMAP扩展来了解所创建消息的UID。最后，使用BURL[SMTP-BURL]扩展将[IMAP-URLAUTH]格式的URL提供给[SUBMIT]服务器进行提交。
The flow involved to support such a use case consists of:
支持此类用例所涉及的流程包括：
M: {to I -- Optional} The client connects to the IMAP server, optionally starts TLS (if data confidentiality is required), authenticates, opens a mailbox ("INBOX" in the example below), and fetches body structures (see [IMAP]).
M:{to I--Optional}客户端连接到IMAP服务器，可以选择启动TLS（如果需要数据保密性），进行身份验证，打开邮箱（“收件箱”，在下面的示例中），并获取正文结构（请参见[IMAP]）。
Example:
例子：
M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "trip.txt") "<960723163407.20117h@washington.example.com>" "Your trip details" "BASE64" 4554 73) "MIXED")) I: A0051 OK completed
M:A0051 UID FETCH 25627（UID BODYSTRUCTURE）I:*161 FETCH（UID 25627 BODYSTRUCTURE）（“文本”“普通”（“字符集”“US-ASCII”）NIL NIL“7BIT”1152 23）（“文本”“普通”（“字符集”“US-ASCII”“名称”“trip.txt”）<960723163407。20117h@washington.example.com>“您的行程详细信息”“BASE64”4554 73“混合”））I:A0051已完成
M: {to I} The client invokes CATENATE (see [IMAP-CATENATE] for details of the semantics and steps) -- this allows the MUA to create messages on the IMAP server using new data combined with one or more message parts already present on the IMAP server.
M:{to I}客户端调用CATENATE（有关语义和步骤的详细信息，请参见[IMAP-CATENATE]），这允许MUA使用新数据结合IMAP服务器上已有的一个或多个消息部分在IMAP服务器上创建消息。
Note that the example for this step doesn't use the LITERAL+ [IMAP-LITERAL+] extension. Without LITERAL+ the new message is constructed using three round trips. If LITERAL+ is used, the new message can be constructed using one round trip.
请注意，此步骤的示例没有使用LITERAL+[IMAP-LITERAL+]扩展名。如果没有LITERAL+，新消息将使用三次往返来构造。如果使用LITERAL+，则可以使用一次往返来构造新消息。
M: A0052 APPEND Sent FLAGS (\Draft \Seen $MDNSent)
CATENATE (TEXT {475}
I: + Ready for literal data
M: Message-ID: <419399E1.6000505@caernarfon.example.org>
M: Date: Thu, 12 Nov 2004 16:57:05 +0000
M: From: Bob Ar <bar@example.org>
M: MIME-Version: 1.0
M: To: foo@example.net
M: Subject: About our holiday trip
M: Content-Type: multipart/mixed;
M: boundary="------------030308070208000400050907"
M:
M: --------------030308070208000400050907
M: Content-Type: text/plain; format=flowed
M:
M: Our travel agent has sent the updated schedule.
M:
M: Cheers,
M: Bob
M: --------------030308070208000400050907
M: URL "/INBOX;UIDVALIDITY=385759045/;
UID=25627/;Section=2.MIME" URL "/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44}
I: + Ready for literal data
M:
M: --------------030308070208000400050907--
M: )
I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed
M: A0052 APPEND Sent FLAGS (\Draft \Seen $MDNSent)
CATENATE (TEXT {475}
I: + Ready for literal data
M: Message-ID: <419399E1.6000505@caernarfon.example.org>
M: Date: Thu, 12 Nov 2004 16:57:05 +0000
M: From: Bob Ar <bar@example.org>
M: MIME-Version: 1.0
M: To: foo@example.net
M: Subject: About our holiday trip
M: Content-Type: multipart/mixed;
M: boundary="------------030308070208000400050907"
M:
M: --------------030308070208000400050907
M: Content-Type: text/plain; format=flowed
M:
M: Our travel agent has sent the updated schedule.
M:
M: Cheers,
M: Bob
M: --------------030308070208000400050907
M: URL "/INBOX;UIDVALIDITY=385759045/;
UID=25627/;Section=2.MIME" URL "/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44}
I: + Ready for literal data
M:
M: --------------030308070208000400050907--
M: )
I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed
M: {to I} The client uses the GENURLAUTH command to request a URLAUTH URL (see [IMAP-URLAUTH]). I: {to M} The IMAP server returns a URLAUTH URL suitable for later retrieval with URLFETCH (see [IMAP-URLAUTH] for details of the semantics and steps).
M:{to I}客户端使用GENURLAUTH命令请求URLAUTH URL（请参见[IMAP-URLAUTH]）。I:{to M}IMAP服务器返回适合以后使用URLFETCH检索的URLAUTH URL（有关语义和步骤的详细信息，请参阅[IMAP-URLAUTH]）。
M: A0053 GENURLAUTH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45;expire=2005-10-
28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
I: * GENURLAUTH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45;expire=
2005-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038"
I: A0053 OK GENURLAUTH completed
M: A0053 GENURLAUTH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45;expire=2005-10-
28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
I: * GENURLAUTH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45;expire=
2005-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038"
I: A0053 OK GENURLAUTH completed
M: {to S} The client connects to the mail Submission Server and starts a new mail transaction. It uses BURL to let the SMTP submit server fetch the content of the message from the IMAP server (see [IMAP-URLAUTH] for details of the semantics and steps -- this allows
M:{to S}客户端连接到邮件提交服务器并启动新的邮件事务。它使用BURL让SMTP提交服务器从IMAP服务器获取消息内容（有关语义和步骤的详细信息，请参见[IMAP-URLAUTH]），这允许
the MUA to authorize the SMTP submit server to access the message composed as a result of the CATENATE step). Note that the second EHLO command is required after a successful STARTTLS command. Also note that there might be a third required EHLO command if the second EHLO response doesn't list any BURL options. Section 8.4.2 demonstrates this.
MUA授权SMTP提交服务器访问作为链接步骤的结果编写的邮件）。请注意，在成功执行STARTTLS命令之后，需要执行第二个EHLO命令。还请注意，如果第二个EHLO响应没有列出任何BURL选项，则可能需要第三个EHLO命令。第8.4.2节对此进行了说明。
S: 220 owlry.example.org ESMTP
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap
S: 250-CHUNKING
S: 250-AUTH PLAIN
S: 250-DSN
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
M: STARTTLS
S: 220 Ready to start TLS
...TLS negotiation, subsequent data is encrypted...
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap
S: 250-CHUNKING
S: 250-AUTH PLAIN
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
M: MAIL FROM:<bob.ar@example.org>
M: RCPT TO:<foo@example.net>
S: 235 2.7.0 PLAIN authentication successful.
S: 250 2.5.0 Address Ok.
S: 250 2.1.5 foo@example.net OK.
M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;
uid=45/;urlauth=submit+bar:internal:
91354a473744909de610943775f92038 LAST
S: 220 owlry.example.org ESMTP
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap
S: 250-CHUNKING
S: 250-AUTH PLAIN
S: 250-DSN
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
M: STARTTLS
S: 220 Ready to start TLS
...TLS negotiation, subsequent data is encrypted...
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap
S: 250-CHUNKING
S: 250-AUTH PLAIN
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
M: MAIL FROM:<bob.ar@example.org>
M: RCPT TO:<foo@example.net>
S: 235 2.7.0 PLAIN authentication successful.
S: 250 2.5.0 Address Ok.
S: 250 2.1.5 foo@example.net OK.
M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;
uid=45/;urlauth=submit+bar:internal:
91354a473744909de610943775f92038 LAST
S: {to I} The mail Submission Server uses URLFETCH to fetch the message to be sent. (See [IMAP-URLAUTH] for details of the semantics and steps. The so-called "pawn-ticket" authorization mechanism uses a URI that contains its own authorization credentials.)
S:{to I}邮件提交服务器使用URLFETCH获取要发送的邮件。（有关语义和步骤的详细信息，请参见[IMAP-URLAUTH]。所谓的“典当票”授权机制使用包含其自身授权凭据的URI。）
I: {to S} Provides the message composed as a result of the CATENATE step).
I:{to S}提供作为CATENATE步骤的结果编写的消息。
The mail Submission Server opens an IMAP connection to the IMAP server:
邮件提交服务器打开到IMAP服务器的IMAP连接：
I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
IMAP server ready
S: a000 STARTTLS
I: a000 Start TLS negotiation now
...TLS negotiation, if successful - subsequent data
is encrypted...
S: a001 LOGIN submitserver secret
I: a001 OK submitserver logged in
S: a002 URLFETCH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038"
I: * URLFETCH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038" {15065}
...message body follows...
I: a002 OK URLFETCH completed
S: a003 LOGOUT
I: * BYE See you later
I: a003 OK Logout successful
I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
IMAP server ready
S: a000 STARTTLS
I: a000 Start TLS negotiation now
...TLS negotiation, if successful - subsequent data
is encrypted...
S: a001 LOGIN submitserver secret
I: a001 OK submitserver logged in
S: a002 URLFETCH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038"
I: * URLFETCH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038" {15065}
...message body follows...
I: a002 OK URLFETCH completed
S: a003 LOGOUT
I: * BYE See you later
I: a003 OK Logout successful
Note that if data confidentiality is not required, the mail Submission Server may omit the STARTTLS command before issuing the LOGIN command.
请注意，如果不需要数据保密性，邮件提交服务器可能会在发出LOGIN命令之前忽略STARTTLS命令。
S: {to M} Submission server assembles the complete message; if the assembly succeeds, it returns OK to the MUA:
S:{to M}提交服务器组装完整的消息；如果装配成功，它将向MUA返回OK：
S: 250 2.5.0 Ok.
S:250 2.5.0正常。
M: {to I} The client marks the message containing the forwarded attachment on the IMAP server.
M:{to I}客户端在IMAP服务器上标记包含转发附件的消息。
M: A0054 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0054 OK STORE completed
M: A0054 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0054 OK STORE completed
Note: the UID STORE command shown above will only work if the marked message is in the currently selected mailbox; otherwise, it requires a SELECT. This command can be omitted, as it simply changes non-operational metadata not essential to client operations or
注意：上面显示的UID STORE命令仅在标记的邮件位于当前所选邮箱中时有效；否则，它需要选择。此命令可以省略，因为它只是更改对客户端操作或应用程序不重要的非操作元数据
interoperability. The untagged FETCH response is due to [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in Section 5.9.
互操作性。未标记的获取响应是由[IMAP-CONDSTORE]引起的。第5.9节介绍了$Forwarded IMAP关键字。
In the [IMAP-URLAUTH]/[SMTP-BURL] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. During submission [SUBMIT], BURL [SMTP-BURL] and BDAT [SMTP-BINARYMIME] commands are used to create the messages from multiple parts. New body parts are supplied using BDAT commands, while existing body parts are referenced using [IMAP-URLAUTH] format URLs in BURL commands.
在柠檬水“转发而不下载”策略的[IMAP-URLAUTH]/[SMTP-BURL]变体中，消息最初是在MUA中合成和编辑的。在提交[SUBMIT]期间，BURL[SMTP-BURL]和BDAT[SMTP-BINARYMIME]命令用于从多个部分创建邮件。使用BDAT命令提供新的身体部位，而使用BURL命令中的[IMAP-URLAUTH]格式URL引用现有身体部位。
The flow involved to support such a use case consists of: M: {to I -- Optional} The client connects to the IMAP server, optionally starts TLS (if data confidentiality is required), authenticates, opens a mailbox ("INBOX" in the example below), and fetches body structures (see [IMAP]).
支持这种用例所涉及的流程包括：M:{to I--Optional}客户端连接到IMAP服务器，可选地启动TLS（如果需要数据保密性），进行身份验证，打开邮箱（“收件箱”，在下面的示例中），并获取主体结构（参见[IMAP]）。
Example:
例子：
M: B0051 UID FETCH 25627 (UID BODYSTRUCTURE) I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "trip.txt") "<960723163407.20117h@washington.example.com>" "Your trip details" "BASE64" 4554 73) "MIXED")) I: B0051 OK completed
M:B0051 UID FETCH 25627（UID BODYSTRUCTURE）I:*161 FETCH（UID 25627 BODYSTRUCTURE）（“文本”“普通”（“字符集”“US-ASCII”）NIL NIL“7BIT”1152 23）（“文本”“普通”（“字符集”“US-ASCII”“名称”“trip.txt”）<960723163407。20117h@washington.example.com>“您的行程详细信息”“BASE64”4554 73“混合”））I:B0051确定完成
M: {to I} The client uses the GENURLAUTH command to request URLAUTH URLs (see [IMAP-URLAUTH]) referencing pieces of the message to be assembled. I: {to M} The IMAP server returns URLAUTH URLs suitable for later retrieval with URLFETCH (see [IMAP-URLAUTH] for details of the semantics and steps).
M:{to I}客户端使用GENURLAUTH命令请求引用要组装的消息片段的URLAUTH URL（请参见[IMAP-URLAUTH]）。I:{to M}IMAP服务器返回适合以后使用URLFETCH检索的URLAUTH URL（有关语义和步骤的详细信息，请参阅[IMAP-URLAUTH]）。
M: B0052 GENURLAUTH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar"
INTERNAL "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
I: * GENURLAUTH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF"
"imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9"
I: B0052 OK GENURLAUTH completed
M: B0052 GENURLAUTH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar"
INTERNAL "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
I: * GENURLAUTH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF"
"imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9"
I: B0052 OK GENURLAUTH completed
M: {to S} The client connects to the mail Submission Server and starts a new mail transaction. It uses BURL to instruct the SMTP submit server to fetch from the IMAP server pieces of the message to be sent (see [SMTP-BURL] for details of the semantics and steps).
M:{to S}客户端连接到邮件提交服务器并启动新的邮件事务。它使用BURL来指示SMTP提交服务器从IMAP服务器获取要发送的消息片段（有关语义和步骤的详细信息，请参阅[SMTP-BURL]）。
Note that the second EHLO command is required after a successful STARTTLS command. The third EHLO command is required if and only if the second EHLO response doesn't list any BURL options. See Section 8.4.1 for an example of submission where the third EHLO command/response is not present.
请注意，在成功执行STARTTLS命令之后，需要执行第二个EHLO命令。当且仅当第二个EHLO响应未列出任何BURL选项时，才需要第三个EHLO命令。第三个EHLO命令/响应不存在的提交示例见第8.4.1节。
S: 220 owlry.example.org ESMTP
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5
S: 250-DSN
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
M: STARTTLS
S: 220 Ready to start TLS
...TLS negotiation, subsequent data is encrypted...
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 220 owlry.example.org ESMTP
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5
S: 250-DSN
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
M: STARTTLS
S: 220 Ready to start TLS
...TLS negotiation, subsequent data is encrypted...
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
S: 235 2.7.0 PLAIN authentication successful.
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap imap://imap.example.org
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: MAIL FROM:<bob.ar@example.org> BODY=BINARY
S: 250 2.5.0 Address Ok.
M: RCPT TO:<foo@example.net>
S: 250 2.1.5 foo@example.net OK.
M: BDAT 475
M: Message-ID: <419399E1.6000505@caernarfon.example.org>
M: Date: Thu, 12 Nov 2004 16:57:05 +0000
M: From: Bob Ar <bar@example.org>
M: MIME-Version: 1.0
M: To: foo@example.net
M: Subject: About our holiday trip
M: Content-Type: multipart/mixed;
M: boundary="------------030308070208000400050907"
M:
M: --------------030308070208000400050907
M: Content-Type: text/plain; format=flowed
M:
M: Our travel agent has sent the updated schedule.
M:
M: Cheers,
M: Bob
M: --------------030308070208000400050907
S: 250 2.5.0 OK
M: BURL imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF
S: 250 2.5.0 OK
M: BURL imap://bob.ar@example.org/INBOX;
S: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
S: 235 2.7.0 PLAIN authentication successful.
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap imap://imap.example.org
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: MAIL FROM:<bob.ar@example.org> BODY=BINARY
S: 250 2.5.0 Address Ok.
M: RCPT TO:<foo@example.net>
S: 250 2.1.5 foo@example.net OK.
M: BDAT 475
M: Message-ID: <419399E1.6000505@caernarfon.example.org>
M: Date: Thu, 12 Nov 2004 16:57:05 +0000
M: From: Bob Ar <bar@example.org>
M: MIME-Version: 1.0
M: To: foo@example.net
M: Subject: About our holiday trip
M: Content-Type: multipart/mixed;
M: boundary="------------030308070208000400050907"
M:
M: --------------030308070208000400050907
M: Content-Type: text/plain; format=flowed
M:
M: Our travel agent has sent the updated schedule.
M:
M: Cheers,
M: Bob
M: --------------030308070208000400050907
S: 250 2.5.0 OK
M: BURL imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF
S: 250 2.5.0 OK
M: BURL imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9
S: 250 2.5.0 OK
M: BDAT 44 LAST
M:
M: --------------030308070208000400050907--
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9
S: 250 2.5.0 OK
M: BDAT 44 LAST
M:
M: --------------030308070208000400050907--
S: {to I} The mail Submission Server uses URLFETCH to fetch the pieces of the message to be sent. (See [SMTP-BURL] for details of the semantics and steps. The so-called "pawn-ticket" authorization mechanism uses a URI which contains its own authorization credentials.). I: {to S} Returns the requested body parts.
S:{to I}邮件提交服务器使用URLFETCH获取要发送的邮件片段。（有关语义和步骤的详细信息，请参见[SMTP-BURL]。所谓的“典当票”授权机制使用一个包含其自身授权凭据的URI。）。I:{to S}返回请求的身体部位。
The mail Submission Server opens an IMAP connection to the IMAP server:
邮件提交服务器打开到IMAP服务器的IMAP连接：
I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
IMAP server ready
S: b000 STARTTLS
I: b000 Start TLS negotiation now
...TLS negotiation, if successful - subsequent data
is encrypted...
S: b001 LOGIN submitserver secret
I: b001 OK submitserver logged in
S: b002 URLFETCH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF" "imap://
bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9"
I: * URLFETCH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF" {84}
...message section follows...
"imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9" {15065}
...message section follows...
I: b002 OK URLFETCH completed
S: b003 LOGOUT
I: * BYE See you later
I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
IMAP server ready
S: b000 STARTTLS
I: b000 Start TLS negotiation now
...TLS negotiation, if successful - subsequent data
is encrypted...
S: b001 LOGIN submitserver secret
I: b001 OK submitserver logged in
S: b002 URLFETCH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF" "imap://
bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9"
I: * URLFETCH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF" {84}
...message section follows...
"imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9" {15065}
...message section follows...
I: b002 OK URLFETCH completed
S: b003 LOGOUT
I: * BYE See you later
I: b003 OK Logout successful
I:b003正常注销成功
Note that if data confidentiality is not required, the mail Submission Server may omit the STARTTLS command before issuing the LOGIN command.
请注意，如果不需要数据保密性，邮件提交服务器可能会在发出LOGIN命令之前忽略STARTTLS命令。
S: {to M} Submission Server assembles the complete message; if the assembly succeeds, it acknowledges acceptance of the message by sending 250 response to the last BDAT command:
S:{to M}提交服务器组装完整的消息；如果程序集成功，它将通过向最后一个BDAT命令发送250个响应来确认接受消息：
S: 250 2.5.0 Ok, message accepted.
S:250 2.5.0正常，接受消息。
M: {to I} The client marks the message containing the forwarded attachment on the IMAP server.
M:{to I}客户端在IMAP服务器上标记包含转发附件的消息。
M: B0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: B0053 OK STORE completed
M: B0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: B0053 OK STORE completed
Note: the UID STORE command shown above will only work if the marked message is in the currently selected mailbox; otherwise, it requires a SELECT. As in the previous example, this command is not critical, and can be omitted. The untagged FETCH response is due to [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in Section 5.9.
注意：上面显示的UID STORE命令仅在标记的邮件位于当前所选邮箱中时有效；否则，它需要选择。与前一个示例一样，此命令不是关键命令，可以省略。未标记的获取响应是由[IMAP-CONDSTORE]引起的。第5.9节介绍了$Forwarded IMAP关键字。
The so-called "pawn-ticket" authorization mechanism uses a URI, which contains its own authorization credentials using [IMAP-URLAUTH]. The advantage of this mechanism is that the SMTP submit [SUBMIT] server cannot access any data on the [IMAP-URLAUTH] server without a "pawn-ticket" created by the client.
所谓的“典当票”授权机制使用一个URI，它使用[IMAP-URLAUTH]包含自己的授权凭证。此机制的优点是，如果没有客户端创建的“当票”，SMTP提交[submit]服务器无法访问[IMAP-URLAUTH]服务器上的任何数据。
The "pawn-ticket" grants access only to the specific data that the SMTP submit [SUBMIT] server is authorized to access, can be revoked by the client, and can have a time-limited validity.
“当票”仅授予SMTP submit[submit]服务器有权访问的特定数据的访问权，该数据可由客户端撤销，并且具有时间限制的有效性。
The "fcc problem" refers to delivering a copy of a message to a mailbox, or "file carbon copy". By far, the most common case of fcc is a client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox" mailbox.
“fcc问题”是指将邮件副本发送到邮箱或“文件副本”。到目前为止，fcc最常见的情况是客户端在“已发送邮件”或“发件箱”邮箱中留下发送邮件的副本。
In the traditional strategy, the MUA duplicates the effort spent in transmitting to the MSA by writing the message to the fcc destination in a separate step. This may be a write to a local disk file or an
在传统策略中，MUA通过在单独的步骤中将消息写入fcc目的地，从而复制了传输到MSA所花费的精力。这可能是对本地磁盘文件的写入或
APPEND to a mailbox on an IMAP server. The latter is one of the "repetitive network data transmissions" that represents the "problem" aspect of the "fcc problem".
附加到IMAP服务器上的邮箱。后者是代表“fcc问题”的“问题”方面的“重复网络数据传输”之一。
The BURL [SMTP-BURL] extension can be used to eliminate the additional transmission. The final message is uploaded to the mailbox designed for outgoing mail by the APPEND command of [IMAP]. Note that when doing so, the client ought to use the $SubmitPending and $Submitted IMAP keywords described in Section 5.10. Also note that APPEND, including when enhanced by [IMAP-CATENATE], can only create a single copy of the message and this is only of use on the server that stages the outgoing message for submission. Additional copies of the message on the same server can be created by using one or more COPY commands.
BURL[SMTP-BURL]扩展可用于消除额外传输。最后一条消息通过[IMAP]的APPEND命令上载到为发送邮件而设计的邮箱。请注意，执行此操作时，客户端应使用第5.10节中描述的$SubmitPending和$Submitted IMAP关键字。还要注意的是，APPEND（包括通过[IMAP-CATENATE]增强时）只能创建消息的单个副本，这仅在将传出消息分段提交的服务器上使用。可以使用一个或多个复制命令在同一服务器上创建邮件的其他副本。
Deployment considerations are discussed extensively in [LEMONADE-DEPLOYMENTS].
[LEMONADE-DEPLOYMENTS]中广泛讨论了部署注意事项。
Implementors are advised to examine the security considerations of all the referenced documents. This section merely highlights these, and advises implementors on specific issues relating to the combination of extensions.
建议实施者检查所有参考文档的安全注意事项。本节仅强调这些，并就与扩展组合相关的特定问题向实现者提供建议。
Security considerations on Lemonade "forward without download" are discussed throughout Section 8. Additional security considerations can be found in [IMAP], [SUBMIT], [SIEVE], and other documents describing other SMTP, IMAP, and Sieve extension comprising the Lemonade Profile.
关于柠檬水“无需下载就转发”的安全注意事项将在第8节中讨论。其他安全注意事项可以在[IMAP]、[SUBMIT]、[SIEVE]和其他描述其他SMTP、IMAP和SIEVE扩展（包括柠檬汁配置文件）的文档中找到。
Note that the mandatory-to-implement authentication mechanism for SMTP submission is described in [SMTP-AUTH]. The mandatory-to-implement authentication mechanism for IMAP is described in [IMAP].
请注意，[SMTP-AUTH]中描述了为SMTP提交实现身份验证机制的强制要求。[IMAP]中描述了为IMAP实现身份验证机制的必要条件。
When clients submit new messages, link protection such as [TLS] guards against an eavesdropper seeing the contents of the submitted message. It is worth noting, however, that even if TLS is not used, the security risks are no worse if BURL is used to reference the text than if the text is submitted directly. If BURL is not used, an eavesdropper gains access to the full text of the message. If BURL is used, the eavesdropper may or may not be able to gain such access,
当客户端提交新消息时，链接保护（如[TLS]）可以防止窃听者看到提交消息的内容。然而，值得注意的是，即使不使用TLS，如果使用BURL引用文本，安全风险也不会比直接提交文本更大。如果未使用BURL，则窃听者可以访问消息的全文。如果使用BURL，窃听者可能会也可能无法获得此类访问权，
depending on the form of BURL used. For example, some forms restrict use of the URL to an entity authorized as a Submission Server or a specific user.
取决于所使用的BURL的形式。例如，某些表单将URL的使用限制为授权为提交服务器的实体或特定用户。
When Lemonade clients use the BURL extension for mail submission, an extension that requires sending a URLAUTH token to the mail Submission Server, such a token should be protected from interception to avoid a replay attack that may disclose the contents of the message to an attacker. [TLS]-based encryption of both the IMAP session that issues GENURLAUTH and the mail submission path will provide protection against this attack.
当Lemonade客户端使用BURL扩展进行邮件提交时，需要向邮件提交服务器发送URLAUTH令牌的扩展，应保护该令牌不被截获，以避免可能向攻击者泄露邮件内容的重播攻击。对发出GENURLAUTH的IMAP会话和邮件提交路径进行基于[TLS]的加密，可防止此攻击。
Lemonade-compliant mail Submission Servers SHOULD use TLS-protected IMAP connections when fetching message content using the URLAUTH token provided by the Lemonade client.
Lemonade兼容的邮件提交服务器在使用Lemonade客户端提供的URLAUTH令牌获取邮件内容时应使用受TLS保护的IMAP连接。
When a client uses SMTP STARTTLS to send a BURL command that references non-public information, there is a user expectation that the entire message content will be treated confidentially. To meet this expectation, the message Submission Server SHOULD use STARTTLS or a mechanism providing equivalent data confidentiality when fetching the content referenced by that URL.
当客户端使用SMTP STARTTLS发送引用非公开信息的BURL命令时，用户期望整个消息内容都会被保密处理。为了满足这一期望，消息提交服务器应该使用STARTTLS或在获取该URL引用的内容时提供等效数据机密性的机制。
This specification provides no additional security measures beyond those in the referenced Internet Mail and Lemonade documents.
除了参考的Internet Mail和Lemonade文档中的安全措施外，本规范不提供其他安全措施。
We note, however, the security risks associated with:
然而，我们注意到与以下相关的安全风险：
o Outband notifications
o 带外通知
o Server configuration by client
o 按客户端的服务器配置
o Client configuration by server
o 按服务器的客户端配置
o Presence of proxy servers
o 代理服务器的存在
o Presence of servers as intermediaries
o 存在作为中介的服务器
o In general, the deployment models considered by OMA MEM that are not conventional IETF deployment models
o 通常，OMA MEM考虑的部署模型不是传统的IETF部署模型
o Measures to address a perceived need to traverse firewalls and mobile network intermediaries
o 解决穿越防火墙和移动网络中介的感知需求的措施
Deployments that provide these additional services or operate in these environments need to consult the security considerations for the relevant standards and organizational security practices.
提供这些附加服务或在这些环境中运行的部署需要参考相关标准和组织安全实践的安全注意事项。
IMAP4 capabilities are registered by IETF Review, as defined in [RFC5226]. This document defines the URL-PARTIAL IMAP capability (Section 5.7.1). IANA added this extension to the IANA IMAP Capability registry.
根据[RFC5226]中的定义，IMAP4能力由IETF Review注册。本文件定义了URL-PARTIAL IMAP功能（第5.7.1节）。IANA将此扩展添加到IANA IMAP功能注册表中。
When compared to RFC 4550, this document adds the following additional requirements on a Lemonade compliant IMAP server:
与RFC 4550相比，本文档在符合柠檬水的IMAP服务器上增加了以下附加要求：
IMAP extensions: BINARY, COMPRESS=DEFLATE, CONTEXT=SEARCH,
CONTEXT=SORT, CONVERT, ENABLE, ESEARCH, ESORT, I18NLEVEL=1,
NOTIFY, QRESYNC, SASL-IR, SORT, URL-PARTIAL;
IMAP extensions: BINARY, COMPRESS=DEFLATE, CONTEXT=SEARCH,
CONTEXT=SORT, CONVERT, ENABLE, ESEARCH, ESORT, I18NLEVEL=1,
NOTIFY, QRESYNC, SASL-IR, SORT, URL-PARTIAL;
IMAP keywords: $SubmitPending, $Submitted.
IMAP关键字：$SubmitPending，$submited。
Other requirements: Require any Lemonade compliant IMAP server to support the CAPABILITY response code.
其他要求：要求任何符合柠檬水标准的IMAP服务器支持功能响应代码。
When compared to RFC 4550, this document adds the following new requirements on a Lemonade compliant Message Delivery Agents:
与RFC 4550相比，本文件对柠檬水兼容的邮件传递代理增加了以下新要求：
Support for the Sieve filtering language, together with the following Sieve extensions:
支持筛过滤语言，以及以下筛扩展：
ENOTIFY, IMAP4FLAGS, RELATIONAL, VACATION, VARIABLES, comparator-i;unicode-casemap.
ENOTIFY、IMAP4FLAGS、关系、假期、变量、比较器-i；unicode案例图。
When compared to RFC 4550, this document recommends use of the DEFLATE compression method for TLS. All other requirements remain the same.
与RFC 4550相比，本文件建议对TLS使用放气压缩方法。所有其他要求保持不变。
Additionally, the following changes/improvments were done to RFC 4550 (the list might be incomplete):
此外，对RFC 4550进行了以下更改/改进（列表可能不完整）：
A new section with some additional requirements on Lemonade Mail User Agents was added, in particular they are required to support Format=flowed parameter to the text/plain media type.
添加了一个新的部分，其中对Lemonade Mail用户代理有一些额外的要求，特别是它们需要支持文本/普通媒体类型的Format=flowed参数。
Usage of the $Forwarded IMAP keyword was clarified.
澄清了$Forwarded IMAP关键字的用法。
Forward-without-download examples were corrected and extended.
转发而不下载示例已更正和扩展。
Added a new section describing in-band and out-of-band notifications from a Lemonade compliant mailstore.
添加了一个新的部分，描述来自符合柠檬水标准的邮件商店的带内和带外通知。
The editors acknowledge and appreciate the work and comments of the IETF Lemonade working group and the OMA MEM working group.
编辑们感谢IETF柠檬水工作组和OMA MEM工作组的工作和评论。
In particular, the editors would like to thank Eric Burger, Glenn Parsons, Randall Gellens, Filip Navara, Zoltan Ordogh, Greg Vaudreuil, and Fan Xiaohui for their comments and reviews.
编辑们尤其要感谢埃里克·伯格、格伦·帕森斯、兰德尔·盖伦斯、菲利普·纳瓦拉、佐尔坦·奥多格、格雷格·沃德鲁伊和范晓辉的评论和评论。
[FLOWED] Gellens, R., "The Text/Plain Format and DelSp Parameters", RFC 3676, February 2004.
[流动]Gellens，R.，“文本/普通格式和DelSp参数”，RFC 3676，2004年2月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[IMAP-BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[IMAP-BINARY]Nerenberg，L.，“IMAP4二进制内容扩展”，RFC3516，2003年4月。
[IMAP-CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
[IMAP-CATENATE]Resnick，P.，“互联网消息访问协议（IMAP）CATENATE扩展”，RFC 4469，2006年4月。
[IMAP-COMPRESS] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, August 2007.
[IMAP-COMPRESS]Gulbrandsen，A.，“IMAP压缩扩展”，RFC 4978，2007年8月。
[IMAP-CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[IMAP-CONDSTORE]Melnikov，A.和S.Hole，“条件存储操作或快速标志更改再同步的IMAP扩展”，RFC 45512006年6月。
[IMAP-CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[IMAP-CONTEXT]Cridland，D.和C.King，“IMAP4的上下文”，RFC 52672008年7月。
[IMAP-CONVERT] Melnikov, A. and P. Coates, "Internet Message Access Protocol - CONVERT Extension", RFC 5259, July 2008.
[IMAP-CONVERT]Melnikov，A.和P.Coates，“互联网消息访问协议-转换扩展”，RFC 5259，2008年7月。
[IMAP-ENABLE] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE Extension", RFC 5161, March 2008.
[IMAP-ENABLE]Gulbrandsen，A.和A.Melnikov，“IMAP启用扩展”，RFC 51612008年3月。
[IMAP-ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006.
[IMAP-ESEARCH]Melnikov，A.和D.Cridland，“用于控制返回何种信息的IMAP4搜索命令扩展”，RFC 47312006年11月。
[IMAP-I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.
[IMAP-I18N]Newman，C.，Gulbrandsen，A.，和A.Melnikov，“互联网消息访问协议国际化”，RFC 52552008年6月。
[IMAP-IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[IMAP-IDLE]Leiba，B.，“IMAP4 IDLE命令”，RFC 2177，1997年6月。
[IMAP-LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[IMAP-LITERAL+]Myers，J.，“IMAP4非同步文字”，RFC 2088，1997年1月。
[IMAP-NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[IMAP-名称空间]Gahrns，M.和C.Newman，“IMAP4名称空间”，RFC 2342，1998年5月。
[IMAP-NOTIFY] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP NOTIFY Extension", RFC 5465, February 2009.
[IMAP-NOTIFY]Gulbrandsen，A.，King，C.和A.Melnikov，“IMAP通知扩展”，RFC 54652009年2月。
[IMAP-QRESYNC] Melnikov, A., Cridland, D., and C. Wilson, "IMAP4 Extensions for Quick Mailbox Resynchronization", RFC 5162, March 2008.
[IMAP-QRESYNC]Melnikov，A.，Cridland，D.，和C.Wilson，“用于快速邮箱重新同步的IMAP4扩展”，RFC 51622008年3月。
[IMAP-SASL-IR] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response", RFC 4959, September 2007.
[IMAP-SASL-IR]Siemborski，R.和A.Gulbrandsen，“简单身份验证和安全层（SASL）初始客户端响应的IMAP扩展”，RFC 49592007年9月。
[IMAP-SORT] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.
[IMAP-SORT]Crispin，M.和K.Murchison，“互联网消息访问协议-排序和线程扩展”，RFC 5256，2008年6月。
[IMAP-UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[IMAP-UIDPLUS]Crispin，M.，“互联网消息访问协议（IMAP）-UIDPLUS扩展”，RFC 4315，2005年12月。
[IMAP-URL] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, November 2007.
[IMAP-URL]Melnikov，A.和C.Newman，“IMAP URL方案”，RFC 5092，2007年11月。
[IMAP-URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[IMAP-URLAUTH]Crispin，M.，“互联网消息访问协议（IMAP）-URLAUTH扩展”，RFC 4467，2006年5月。
[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月。
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[筛]Guenther，P.和T.Showalter，“筛：电子邮件过滤语言”，RFC 52282008年1月。
[SIEVE-IMAP4FLAGS] Melnikov, A., "Sieve Email Filtering: Imap4flags Extension", RFC 5232, January 2008.
[SIEVE-IMAP4FLAGS]Melnikov，A.，“SIEVE电子邮件过滤：IMAP4FLAGS扩展”，RFC 5232，2008年1月。
[SIEVE-NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009.
[SIEVE-NOTIFY]Melnikov，A.，Leiba，B.，Segmuller，W.，和T.Martin，“SIEVE电子邮件过滤：通知扩展”，RFC 54352009年1月。
[SIEVE-RELATIONAL] Segmuller, W. and B. Leiba, "Sieve Email Filtering: Relational Extension", RFC 5231, January 2008.
[SIEVE-RELATIONAL]Segmuller，W.和B.Leiba，“SIEVE电子邮件过滤：关系扩展”，RFC 52312008年1月。
[SIEVE-VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[SIEVE-VACATION]Showalter，T.和N.Freed，“SIEVE电子邮件过滤：假期延长”，RFC 5230，2008年1月。
[SIEVE-VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[SIEVE-VARIABLES]Homme，K.，“SIEVE电子邮件过滤：变量扩展”，RFC 52292008年1月。
[SMTP-8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[SMTP-8BITMIME]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“8bit MIMEtransport的SMTP服务扩展”，RFC 16521994年7月。
[SMTP-AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[SMTP-AUTH]Siemborski，R.和A.Melnikov，“用于身份验证的SMTP服务扩展”，RFC 49542007年7月。
[SMTP-BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[SMTP-BINARYMIME]Vaudreuil，G.，“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 3030，2000年12月。
[SMTP-BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[SMTP-BURL]Newman，C.，“邮件提交BURL扩展”，RFC 4468，2006年5月。
[SMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[SMTP-DSN]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[SMTP-PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[SMTP-pipelling]Freed，N.，“用于命令管道的SMTP服务扩展”，STD 60，RFC 2920，2000年9月。
[SMTP-SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
[SMTP-SIZE]Klensin，J.，Freed，N.，和K.Moore，“邮件大小声明的SMTP服务扩展”，STD 10，RFC 1870，1995年11月。
[SMTP-STATUSCODES] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[SMTP-STATUSCODES]Freed，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 2034，1996年10月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over the Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，2002年2月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提交]Gellens，R.和J.Klensin，“邮件信息提交”，RFC 4409，2006年4月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[TLS-COMP] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004.
[TLS-COMP]Hollenbeck，S.，“传输层安全协议压缩方法”，RFC 3749，2004年5月。
[UNICODE-CASEMAP] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007.
[UNICODE-CASEMAP]Crispin，M.，“i；UNICODE CASEMAP-简单UNICODE排序算法”，RFC 5051，2007年10月。
[ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[ESMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[Err1807] RFC Errata, Errata ID 1807, RFC 5162, <http://www.rfc-editor.org>.
[Err1807]RFC勘误表，勘误表ID 1807，RFC 5162<http://www.rfc-editor.org>.
[Err1808] RFC Errata, Errata ID 1808, RFC 5162, <http://www.rfc-editor.org>.
[Err1808]RFC勘误表，勘误表ID 1808，RFC 5162<http://www.rfc-editor.org>.
[Err1809] RFC Errata, Errata ID 1809, RFC 5162, <http://www.rfc-editor.org>.
[Err1809]RFC勘误表，勘误表ID 1809，RFC 5162<http://www.rfc-editor.org>.
[Err1810] RFC Errata, Errata ID 1810, RFC 5162, <http://www.rfc-editor.org>.
[Err1810]RFC勘误表，勘误表ID 1810，RFC 5162<http://www.rfc-editor.org>.
[FINGER-HACK] Gellens, R., "Simple New Mail Notification", RFC 4146, August 2005.
[FINGER-HACK]Gellens，R.，“简单的新邮件通知”，RFC 41462005年8月。
[IMAP-FILTERS] Melnikov, A. and C. King, "IMAP4 Extension for Named Searches (Filters)", RFC 5466, February 2009.
[IMAP-FILTERS]Melnikov，A.和C.King，“命名搜索（过滤器）的IMAP4扩展”，RFC 5466，2009年2月。
[IMAP-SYNC-HOWTO] Melnikov, A., "Synchronization Operations for Disconnected IMAP4 Clients", RFC 4549, June 2006.
[IMAP-SYNC-HOWTO]Melnikov，A.，“断开连接的IMAP4客户端的同步操作”，RFC 4549，2006年6月。
[LEMONADE-ARCH] Burger, E. and G. Parsons, "LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail", RFC 5442, March 2009.
[LEMONADE-ARCH]Burger，E.和G.Parsons，“柠檬水体系结构-支持使用互联网邮件的开放移动联盟（OMA）移动电子邮件（MEM）”，RFC 54422009年3月。
[LEMONADE-DEPLOYMENTS] Gellens, R., "Deployment Considerations for Lemonade-Compliant Mobile Email", BCP 143, RFC 5383, October 2008.
[柠檬水部署]Gellens，R.，“柠檬水兼容移动电子邮件的部署注意事项”，BCP 143，RFC 5383，2008年10月。
[LEMONADE-NOTIFICATIONS] Gellens, R., Ed., "Lemonade Notifications Architecture", RFC 5551, August 2009.
[柠檬水通知]Gellens，R.，编辑，“柠檬水通知体系结构”，RFC 55512009年8月。
[MANAGESIEVE] Melnikov, A. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", Work in Progress, September 2008.
[管理筛]Melnikov，A.和T.Martin，“远程管理筛脚本的协议”，正在进行的工作，2008年9月。
[METADATA] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.
[元数据]Daboo，C.，“IMAP元数据扩展”，RFC 54642009年2月。
[OMA-EMN] Open Mobile Alliance, "Open Mobile Alliance Email Notification Version 1.0", OMA http:// www.openmobilealliance.org/Technical/release_program/ emn_v10.aspx, October 2007.
[OMA-EMN]开放移动联盟，“开放移动联盟电子邮件通知版本1.0”，OMA http://www.openmobilealliance.org/Technical/release\u program/EMN\u v10.aspx，2007年10月。
[OMA-MEM-ARCH] Open Mobile Alliance, "Mobile Email Architecture Document", OMA (Work in Progress), http://www.openmobilealliance.org/, October 2005.
[OMA-MEM-ARCH]开放移动联盟，“移动电子邮件架构文档”，OMA（正在进行的工作），http://www.openmobilealliance.org/，2005年10月。
[OMA-MEM-REQ] Open Mobile Alliance, "Mobile Email Requirements Document", OMA http://www.openmobilealliance.org/ release_program/docs/RD/ OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005.
[OMA-MEM-REQ]开放移动联盟，“移动电子邮件需求文档”，OMAhttp://www.openmobilealliance.org/ 发布计划/docs/RD/OMA-RD-MobileEmail-V1\u 0\u 20051018-C.pdf，2005年10月。
[RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. Finch, "Email Submission Operations: Access and Accountability Requirements", BCP 134, RFC 5068, November 2007.
[RFC5068]Hutzler，C.，Crocker，D.，Resnick，P.，Allman，E.，和T.Finch，“电子邮件提交操作：访问和责任要求”，BCP 134，RFC 5068，2007年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC5598，2009年7月。
Errata ID: 1807 [Err1807]
勘误表ID:1807[Err1807]
Status: Verified Type: Technical
状态：已验证类型：技术
Reported By: Timo Sirainen Date Reported: 2009-07-14 Verifier Name: Alexey Melnikov Date Verified: 2009-07-18
报告人：Timo Sirainen报告日期：2009-07-14验证人姓名：Alexey Melnikov验证日期：2009-07-18
Section 1 says:
第一节说：
It should say:
它应该说：
Once a "CONDSTORE enabling command" is issued by the client, the server MUST automatically include both UID and mod-sequence data in all subsequent untagged FETCH responses (until the connection is closed), whether they were caused by a regular STORE/UID STORE, a STORE/UID STORE with UNCHANGEDSINCE modifier, or an external agent. Note that this rule doesn't affect untagged FETCH responses caused by a FETCH command that doesn't include UID and/or MODSEQ FETCH data item, or UID FETCH without the MODSEQ FETCH data item.
一旦客户端发出“CONDSTORE enabling command”，服务器必须在所有后续未标记的获取响应中自动包含UID和mod序列数据（直到连接关闭），无论它们是由常规存储/UID存储、带有UNCHANGEDSINCE修饰符的存储/UID存储或外部代理引起的。请注意，此规则不影响由不包含UID和/或MODSEQ FETCH数据项的FETCH命令或不包含MODSEQ FETCH数据项的UID FETCH命令引起的未标记的FETCH响应。
Notes:
笔记：
Rationale:
理论基础：
It's very difficult for clients to make use of unsolicited FETCH responses without the UID field. This is made even worse by the text that says "servers SHOULD NOT send UIDs for previously expunged messages [in VANISHED replies]". Since it's not a MUST NOT, a conversation with an RFC compliant server could be for example:
如果没有UID字段，客户端很难使用未经请求的获取响应。更糟糕的是，文本中说“服务器不应该为[消失的回复]中先前删除的邮件发送UID”。由于这不是必须的，因此与RFC兼容服务器的对话可以是：
A1 NOOP * 0 EXISTS A1 OK A2 NOOP * 10 EXISTS * VANISHED 1000:2000 * 3 FETCH (FLAGS (\Seen) MODSEQ (14749)) * 5 FETCH (FLAGS (\Seen) MODSEQ (14749)) * VANISHED 2000:3000 A2 OK NOOP Completed
A1 NOOP*0存在A1 OK A2 NOOP*10存在*消失1000:2000*3取数（标志（\Seen）MODSEQ（14749））*5取数（标志（\Seen）MODSEQ（14749））*消失2000:3000 A2 OK NOOP已完成
The client couldn't do anything with the information from FETCH replies, because it can't know what messages they refer to.
客户端无法处理来自获取回复的信息，因为它不知道它们引用的是什么消息。
Errata ID: 1808 [Err1808]
勘误表ID:1808[Err1808]
Status: Verified Type: Technical
状态：已验证类型：技术
Reported By: Timo Sirainen Date Reported: 2009-07-14 Verifier Name: Alexey Melnikov Date Verified: 2009-07-18
报告人：Timo Sirainen报告日期：2009-07-14验证人姓名：Alexey Melnikov验证日期：2009-07-18
Section 3.4 says:
第3.4节说：
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.
如果至少有一封邮件被删除，服务器必须使用标记的OK响应中的HIGHESTMODSEQ响应代码（在[CONDSTORE]中定义）发送更新的每个邮箱修改序列。
Example: C: A202 CLOSE S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
示例：C:A202关闭S:A202正常[最高ModSeq 20010715194045319]完成
It should say:
它应该说：
The server MUST NOT send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response, as this might cause loss of synchronization on the client.
服务器不得使用标记的OK响应中的HIGHESTMODSEQ响应代码（在[CONDSTORE]中定义）发送更新的每个邮箱修改序列，因为这可能会导致客户端上的同步丢失。
Example: C: A202 CLOSE S: A202 OK done
示例：C:A202关闭S:A202确定完成
Notes:
笔记：
Rationale:
理论基础：
The HIGHESTMODSEQ can't be used reliably unless server sends to client all changes done by other clients. Even then it's difficult for both clients and servers to implement this. For example:
除非服务器将其他客户端所做的所有更改发送给客户端，否则无法可靠地使用HIGHESTMODSEQ。即使这样，客户机和服务器也很难实现这一点。例如：
C1: 2 STORE 1 +FLAGS.SILENT \Deleted
S1: * 1 FETCH (MODSEQ 1)
S1: 2 OK
C1: 2 STORE 1 +FLAGS.SILENT \Deleted
S1: * 1 FETCH (MODSEQ 1)
S1: 2 OK
C2: 1 STORE 2 +FLAGS.SILENT \Deleted
S1: * 2 FETCH (MODSEQ 2)
S2: 1 OK
C2: 1 STORE 2 +FLAGS.SILENT \Deleted
S1: * 2 FETCH (MODSEQ 2)
S2: 1 OK
C1: 3 CLOSE S1: 3 [HIGHESTMODSEQ 3]
C1:3收盘S1:3[最高ModSeq 3]
The client probably thought that only message 1 was expunged, so it doesn't register the second expunge. And it probably never will if it uses QRESYNC to find out only about new expunges.
客户端可能认为只有消息1被删除，所以它没有注册第二次删除。如果它只使用QRESYNC查找新的删除，它可能永远也不会这样做。
And even worse example would be if the second client had also removed the \Deleted flag from message 1. Then the first client would have registered wrong message to be expunged.
更糟糕的例子是，如果第二个客户端也从消息1中删除了\Deleted标志。那么第一个客户机将注册错误的消息以被删除。
Errata ID: 1809 [Err1809]
勘误表ID:1809[Err1809]
Status: Verified Type: Technical
状态：已验证类型：技术
Reported By: Timo Sirainen Date Reported: 2009-07-14 Verifier Name: Alexey Melnikov Date Verified: 2009-07-18
报告人：Timo Sirainen报告日期：2009-07-14验证人姓名：Alexey Melnikov验证日期：2009-07-18
Section 5 says:
第5节说：
After completing a full synchronization, the client MUST also take note of any unsolicited MODSEQ FETCH data items received from the server. Whenever the client receives a tagged response to a command, it calculates the highest value among all MODSEQ FETCH data items received since the last tagged response. If this value is bigger than the client's copy of the HIGHESTMODSEQ value, then the client MUST use this value as its new HIGHESTMODSEQ value.
完成完全同步后，客户端还必须注意从服务器收到的任何未经请求的MODSEQ FETCH数据项。每当客户端收到对命令的标记响应时，它都会计算自上次标记响应以来收到的所有MODSEQ FETCH数据项中的最高值。如果此值大于客户端的HIGHESTMODSEQ值副本，则客户端必须使用此值作为其新的HIGHESTMODSEQ值。
Note: It is not safe to update the client's copy of the HIGHESTMODSEQ value with a MODSEQ FETCH data item value as soon as it is received because servers are not required to send MODSEQ FETCH data items in increasing modseqence order. This can lead to the client missing some changes in case of connectivity loss.
注意：在收到最高MODSEQ值后，立即使用MODSEQ FETCH数据项值更新客户端的最高MODSEQ值副本是不安全的，因为服务器不需要以递增的ModSequence顺序发送MODSEQ FETCH数据项。这可能导致客户端在连接丢失时丢失一些更改。
It should say:
它应该说：
After completing a full synchronization, the client MUST also take note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ response codes received from the server. Whenever the client receives a tagged response to a command, it checks the received unsolicited responses to calculate the new HIGHESTMODSEQ value. If the HIGHESTMODSEQ response code is received, the client MUST use it even if it has seen higher mod-sequences. Otherwise, the client calculates the highest value among all MODSEQ FETCH data items received since the last tagged response. If this value is bigger than the client's copy of the HIGHESTMODSEQ value, then the client MUST use this value as its new HIGHESTMODSEQ value.
完成完全同步后，客户端还必须注意从服务器接收到的任何未经请求的MODSEQ获取数据项和最高级MODSEQ响应代码。每当客户端收到对命令的标记响应时，它都会检查收到的未经请求的响应，以计算新的HIGHESTMODSEQ值。如果接收到最高位ModSeq响应代码，客户机必须使用它，即使它看到了较高的mod序列。否则，客户端将计算自上次标记响应以来接收的所有MODSEQ FETCH数据项中的最高值。如果此值大于客户端的HIGHESTMODSEQ值副本，则客户端必须使用此值作为其新的HIGHESTMODSEQ值。
Example: C: A1 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen
S: * 1 FETCH (UID 6 MODSEQ (103))
S: * 2 FETCH (UID 7 MODSEQ (101))
S: * OK [HIGHESTMODSEQ 99] VANISHED reply with
MODSEQ 100 is delayed
S: A1 OK [MODIFIED 3] done
Example: C: A1 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen
S: * 1 FETCH (UID 6 MODSEQ (103))
S: * 2 FETCH (UID 7 MODSEQ (101))
S: * OK [HIGHESTMODSEQ 99] VANISHED reply with
MODSEQ 100 is delayed
S: A1 OK [MODIFIED 3] done
C: A2 STORE 3 +FLAGS.SILENT \Seen
S: * 3 FETCH (UID 8 MODSEQ (104))
S: A2 OK [HIGHESTMODSEQ 99] Still delaying VANISHED
C: A2 STORE 3 +FLAGS.SILENT \Seen
S: * 3 FETCH (UID 8 MODSEQ (104))
S: A2 OK [HIGHESTMODSEQ 99] Still delaying VANISHED
C: A3 NOOP
S: * VANISHED 8
S: A3 OK [HIGHESTMODSEQ 104] done
C: A3 NOOP
S: * VANISHED 8
S: A3 OK [HIGHESTMODSEQ 104] done
Note: It is not safe to update the client's copy of the HIGHESTMODSEQ value with a MODSEQ FETCH data item value as soon as it is received because servers are not required to send MODSEQ FETCH data items in increasing modseqence order. Some commands may also delay EXPUNGE (or VANISHED) replies with smaller mod-sequences. These can lead to the client missing some changes in case of connectivity loss.
注意：在收到最高MODSEQ值后，立即使用MODSEQ FETCH数据项值更新客户端的最高MODSEQ值副本是不安全的，因为服务器不需要以递增的ModSequence顺序发送MODSEQ FETCH数据项。某些命令还可能延迟使用较小的mod序列进行删除（或消失）回复。这些可能会导致客户端在连接丢失时丢失一些更改。
Notes:
笔记：
Rationale:
理论基础：
Otherwise clients could lose changes in case of connectivity loss.
否则，如果连接丢失，客户端可能会丢失更改。
Errata ID: 1810 [Err1810]
勘误表ID:1810[错误1810]
Status: Verified Type: Technical
状态：已验证类型：技术
Reported By: Timo Sirainen Date Reported: 2009-07-14 Verifier Name: Alexey Melnikov Date Verified: 2009-07-18
报告人：Timo Sirainen报告日期：2009-07-14验证人姓名：Alexey Melnikov验证日期：2009-07-18
Section 1 says:
第一节说：
It should say:
它应该说：
Server implementing QRESYNC MUST send untagged events to client in a way that client doesn't lose any changes in case of connectivity loss. In particular this means that if server sends MODSEQ FETCH data items while EXPUNGE (or VANISHED) replies with lower mod-sequences are being delayed, the server MUST send HIGHESTMODSEQ response code with a lower value than the EXPUNGE's mod-sequence. See example in section 5.
实现QRESYNC的服务器必须向客户端发送未标记的事件，以便客户端在连接丢失时不会丢失任何更改。特别是，这意味着，如果服务器发送MODSEQ FETCH数据项，而具有较低mod序列的删除（或消失）响应被延迟，则服务器必须发送值低于删除的mod序列的最高位MODSEQ响应代码。参见第5节中的示例。
Notes:
笔记：
This is related to the other errata in section 5, which describes what the client's behavior should be. This describes what the server's behavior should be. Would have been nice to put them into the same section, but that probably would require larger changes.
这与第5节中的其他勘误表有关，该勘误表描述了客户的行为。这描述了服务器的行为应该是什么。如果将它们放在同一个部分中会很好，但这可能需要更大的更改。
Authors' Addresses
作者地址
Dave Cridland (editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Dave Cridland（编辑）Isode Limited 5 Castle Business Village 36 Station Road Hampton，Middlesex TW12 2BX英国
EMail: dave.cridland@isode.com
EMail: dave.cridland@isode.com
Alexey Melnikov (editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov（编辑）Isode Limited 5城堡商业村英国米德尔塞克斯郡汉普顿车站路36号TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Stephane H. Maes (editor) Oracle MS 4op634, 500 Oracle Parkway Redwood Shores, CA 94539 USA
Stephane H.Maes（编辑）甲骨文MS 4op634，美国加利福尼亚州甲骨文公园路红木海岸500号，邮编94539
Phone: +1-203-300-7786
EMail: stephane.maes@oracle.com
Phone: +1-203-300-7786
EMail: stephane.maes@oracle.com