Network Working Group S. Maes
Request for Comments: 4550 Oracle
Category: Standards Track A. Melnikov
Isode Ltd.
June 2006
Network Working Group S. Maes
Request for Comments: 4550 Oracle
Category: Standards Track A. Melnikov
Isode Ltd.
June 2006
Internet Email to Support Diverse Service Environments (Lemonade) Profile
支持多种服务环境的Internet电子邮件（柠檬水）配置文件
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission 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和邮件提交协议的概要文件（一组必需的扩展、限制和使用模式）。此配置文件允许客户端（特别是那些在内存、带宽、处理能力或其他方面受到限制的客户端）高效地使用IMAP和Submission来访问和提交邮件。这包括转发收到的邮件而无需下载和上载邮件、优化提交以及在与服务器失去连接时高效地重新同步的能力。
The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409).
支持多样化服务环境（柠檬水）的互联网电子邮件模式依赖于对IMAP和邮件提交协议的扩展；具体来说，URLAUTH和CATENATE IMAP协议（RFC 3501）扩展和提交协议（RFC 4409）的BURL扩展。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Forward without Download ........................................3
2.1. Motivations ................................................3
2.2. Message Sending Overview ...................................4
2.3. Traditional Strategy .......................................4
2.4. Step-by-Step Description ...................................5
2.4.1. Message Assembly Using IMAP CATENATE Extension ......6
2.4.2. Message Assembly Using SMTP CHUNKING and
BURL Extensions ....................................10
2.5. Normative Statements Related to Forward without Download ..14
2.6. Security Considerations for "pawn-tickets" ................14
2.7. The fcc Problem ...........................................15
2.8. Registration of $Forwarded IMAP Keyword ...................15
3. Message Submission .............................................15
3.1. Pipelining ................................................16
3.2. DSN Support ...............................................16
3.3. Message Size Declaration ..................................16
3.4. Enhanced Status Code Support ..............................16
3.5. TLS .......................................................16
4. Quick Resynchronization ........................................16
5. Additional IMAP Extensions .....................................17
6. Summary of the Required IMAP and SMTP Extensions ...............17
7. Future work ....................................................18
8. Security Considerations ........................................18
8.1. Confidentiality Protection of Submitted Messages ..........19
8.2. TLS .......................................................19
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
10. Acknowledgements ..............................................21
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Forward without Download ........................................3
2.1. Motivations ................................................3
2.2. Message Sending Overview ...................................4
2.3. Traditional Strategy .......................................4
2.4. Step-by-Step Description ...................................5
2.4.1. Message Assembly Using IMAP CATENATE Extension ......6
2.4.2. Message Assembly Using SMTP CHUNKING and
BURL Extensions ....................................10
2.5. Normative Statements Related to Forward without Download ..14
2.6. Security Considerations for "pawn-tickets" ................14
2.7. The fcc Problem ...........................................15
2.8. Registration of $Forwarded IMAP Keyword ...................15
3. Message Submission .............................................15
3.1. Pipelining ................................................16
3.2. DSN Support ...............................................16
3.3. Message Size Declaration ..................................16
3.4. Enhanced Status Code Support ..............................16
3.5. TLS .......................................................16
4. Quick Resynchronization ........................................16
5. Additional IMAP Extensions .....................................17
6. Summary of the Required IMAP and SMTP Extensions ...............17
7. Future work ....................................................18
8. Security Considerations ........................................18
8.1. Confidentiality Protection of Submitted Messages ..........19
8.2. TLS .......................................................19
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
10. Acknowledgements ..............................................21
Lemonade provides enhancements to Internet email to support diverse service environments.
Lemonade为Internet电子邮件提供了增强功能，以支持不同的服务环境。
This document describes the Lemonade profile, which includes:
本文档介绍柠檬水概况，其中包括：
- "forward without download", which describes exchanges between Lemonade clients and servers to allow new email messages to be submitted incorporating content that resides on locations external to the client.
- “转发而不下载”，它描述了柠檬水客户端和服务器之间的交换，以允许提交包含驻留在客户端外部位置的内容的新电子邮件。
- Quick mailbox resynchronization using [CONDSTORE].
- 使用“快速重新同步邮箱”存储。
- Several IMAP and SMTP extensions that save bandwidth and/or number of round-trips required to send/receive data.
- 多个IMAP和SMTP扩展，可节省发送/接收数据所需的带宽和/或往返次数。
The organization of this document is as follows. Section 2 describes "forward without download". Section 3 describes additional SMTP extensions that must be supported by all Lemonade Submission servers. Section 4 describes IMAP quick resynchronization.
本文件的组织结构如下。第2节描述了“不下载转发”。第3节描述了所有Lemonade提交服务器必须支持的其他SMTP扩展。第4节介绍IMAP快速重新同步。
In examples, "M:", "I:", and "S:" indicate lines sent by the client messaging user agent, IMAP e-mail 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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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 Lemonade Submit and IMAP servers support all Lemonade extensions described in this document, so they don't show how to deal with absence of an extension.
本文档中的所有示例都针对柠檬水的使用进行了优化，并且可能不代表通用Submit/IMAP客户端的正确协议使用示例。特别是，示例假设Lemonade Submit和IMAP服务器支持本文中描述的所有Lemonade扩展，所以它们没有说明如何处理缺少扩展的情况。
The advent of client/server email using the [RFC3501], [RFC2821], and [SUBMIT] protocols has changed what formerly were local disk operations into repetitive network data transmissions.
使用[RFC3501]、[RFC2821]和[SUBMIT]协议的客户机/服务器电子邮件的出现，将以前的本地磁盘操作转变为重复的网络数据传输。
Lemonade "forward without download" makes use of the [BURL] SUBMIT 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“转发而不下载”利用[BURL]提交扩展来在提交消息期间访问外部源。与IMAP[URLAUTH]扩展相结合，可以通过IMAP和SMTP提交服务器之间的最小信任关系，包含来自IMAP邮件存储的邮件部分甚至整个邮件。
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/SMTP [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 Post Office Protocol (POP), Network News Transfer Protocol (NNTP), or whatever else may be designed in the future.
Lemonade“无下载转发”的优点是维护一个提交协议，从而避免了使用多个并行且可能不同的提交机制的风险。客户端可以使用Submit/SMTP[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 Mail User Agent (MUA). Frequently, users choose to save more complex messages on an [RFC3501] server (via the APPEND command with the \Draft flag) for later recall by the MUA and resumption of the editing process.
在邮件用户代理（MUA）中启动新草稿和草稿编辑。通常，用户选择在[RFC3501]服务器上保存更复杂的消息（通过带有\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 [RFC2821] infrastructure, typically using the [SUBMIT] protocol.
消息提交是将组装好的消息插入[RFC2821]基础结构的过程，通常使用[SUBMIT]协议。
Traditionally, messages are initiated, edited, and assembled entirely within an MUA, although drafts may be saved to an [RFC3501] server and later retrieved from the server. The completed text is then transmitted to a Message Submission Agent (MSA) for delivery.
传统上，消息完全在MUA中启动、编辑和组装，尽管草稿可能保存到[RFC3501]服务器，然后从服务器检索。然后将完成的文本传输到消息提交代理（MSA）进行交付。
There is often no clear boundary between the editing and assembly process. 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 retrieve 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 among a Mail User Agent (MUA), an IMAP4Rev1 Server ([RFC3501]), and a SMTP submit server ([SUBMIT]), as illustrated in Figure 1.
该模型区分邮件用户代理（MUA）、IMAP4Rev1服务器（[RFC3501]）和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 Messaging User Agent to compose and forward an e-mail combining fragments that are located in an IMAP server, without having to download these fragments to the client.
Lemonade“转发而不下载”允许消息传递用户代理编写和转发电子邮件，该电子邮件组合了位于IMAP服务器中的片段，而无需将这些片段下载到客户端。
There are two ways to perform "forward without download", based on where the message assembly takes place. The first uses an extended APPEND command [CATENATE] to edit a draft message in the message store and cause the message assembly on the IMAP server. 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.
有两种方法可以根据消息汇编发生的位置执行“转发而不下载”。第一种方法使用扩展的APPEND命令[CATENATE]编辑消息存储中的草稿消息，并在IMAP服务器上生成消息程序集。第二种方法使用一系列BURL和BDAT命令来提交和组装（通过连接）来自客户端的消息数据和从提供的URL获取的外部数据。接下来的两个部分提供了如何实现“无下载转发”的分步说明。
In the [BURL]/[CATENATE] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. The [CATENATE] extension to [RFC3501] is then used to create the messages on the IMAP server by transmitting new text and assembling them. The [UIDPLUS] IMAP extension is used by the client in order to learn the Unique Identifier (UID) of the created messages. Finally, a [URLAUTH] format URL is given to a [SUBMIT] server for submission using the [BURL] extension.
在柠檬水“转发而不下载”策略的[BURL]/[CATENATE]变体中，消息最初是在MUA中合成和编辑的。然后使用[RFC3501]的[CATENATE]扩展在IMAP服务器上创建消息，方法是传输新文本并将其组合。客户端使用[UIDPLUS]IMAP扩展来了解所创建消息的唯一标识符（UID）。最后，使用[BURL]扩展将[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 [RFC3501]).
M:{to I--Optional}客户端连接到IMAP服务器，可以选择启动TLS（如果需要数据保密性），进行身份验证，打开邮箱（“下例中的收件箱”）并获取正文结构（请参见[RFC3501]）。
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 [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（有关语义和步骤的详细信息，请参见[CATENATE]）——这允许MUA使用新数据结合IMAP服务器上已有的一个或多个消息部分在IMAP服务器上创建消息。
Note that the example for this step doesn't use the LITERAL+ [LITERAL+] extension. Without LITERAL+, the new message is constructed using 3 round-trips. If LITERAL+ is used, the new message can be constructed using one round-trip.
请注意，此步骤的示例没有使用LITERAL+[LITERAL+]扩展名。如果没有LITERAL+，新消息将使用3次往返来构造。如果使用LITERAL+，则可以使用一次往返来构造新消息。
M: A0052 APPEND Sent FLAGS (\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 (\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 GENURLAUTH command to request a URLAUTH URL (see [URLAUTH]).
M:{to I}客户端使用GENURLAUTH命令请求URLAUTH URL（请参见[URLAUTH]）。
I: {to M} The IMAP server returns a URLAUTH URL suitable for later retrieval with URLFETCH (see [URLAUTH] for details of the semantics and steps).
I:{to M}IMAP服务器返回一个适合以后使用URLFETCH检索的URLAUTH URL（有关语义和步骤的详细信息，请参见[URLAUTH]）。
M: A0054 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: A0054 OK GENURLAUTH completed
M: A0054 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: A0054 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
M:{to S}客户端连接到邮件提交服务器并启动新的邮件事务。让SMTP使用从BURP提交邮件的内容
server. (See [BURL] for details of the semantics and steps.) This allows 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 2.4.2 demonstrates this.
服务器（有关语义和步骤的详细信息，请参见[BURL]）这允许MUA授权SMTP提交服务器访问由CATENATE步骤生成的邮件。请注意，在成功执行STARTTLS命令之后，需要执行第二个EHLO命令。还请注意，如果第二个EHLO响应没有列出任何BURL选项，则可能需要第三个EHLO命令。第2.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=
S: 235 2.7.0 PLAIN authentication successful.
M: MAIL FROM:<bob.ar@example.org>
S: 250 2.5.0 Address Ok.
M: RCPT TO:<foo@example.net>
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=
S: 235 2.7.0 PLAIN authentication successful.
M: MAIL FROM:<bob.ar@example.org>
S: 250 2.5.0 Address Ok.
M: RCPT TO:<foo@example.net>
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 [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获取要发送的邮件。（有关语义和步骤的详细信息，请参见[URLAUTH]。所谓的“典当票”授权机制使用包含其自身授权凭据的URI。）
I: {to S} Provides the message composed as a result of the CATENATE step.
I:{to S}提供作为CATENATE步骤的结果编写的消息。
Mail submission server opens 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...
S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: 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...
S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: a003 OK Logout successful
Note that if the IMAP server doesn't send CAPABILITY response code in the greeting, the mail submission server must issue the CAPABILITY command to learn about supported IMAP extensions as described in RFC 3501.
请注意，如果IMAP服务器未在问候语中发送功能响应代码，则邮件提交服务器必须发出CAPABILITY命令，以了解RFC 3501中所述的受支持的IMAP扩展。
Also, 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, and 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: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 OK STORE completed
M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 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. The untagged FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword is described in Section 2.8.
注意：上面显示的UID STORE命令仅在标记的邮件位于当前所选邮箱中时有效；否则，它需要选择。此命令可以省略。未标记的获取响应是由[CONDSTORE]引起的。第2.8节介绍了$Forwarded IMAP关键字。
In the [BURL]/[CHUNKING] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. During submission [SUBMIT], BURL [BURL] and BDAT [CHUNKING] 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 [URLAUTH] format URLs in BURL commands.
在柠檬水“转发而不下载”策略的[BURL]/[CHUNKING]变体中，消息最初是在MUA中合成和编辑的。在提交[SUBMIT]期间，BURL[BURL]和BDAT[CHUNKING]命令用于从多个部分创建消息。使用BDAT命令提供新的身体部位，而使用BURL命令中的[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 [RFC3501]).
M:{to I--Optional}客户端连接到IMAP服务器，可以选择启动TLS（如果需要数据保密性），进行身份验证，打开邮箱（“收件箱”，在下面的示例中），并获取正文结构（请参见[RFC3501]）。
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 uses GENURLAUTH command to request URLAUTH URLs (see [URLAUTH]) referencing pieces of the message to be assembled.
M:{to I}客户端使用GENURLAUTH命令请求引用要组装的消息片段的URLAUTH URL（请参见[URLAUTH]）。
I: {to M} The IMAP server returns URLAUTH URLs suitable for later retrieval with URLFETCH (see [URLAUTH] for details of the semantics and steps).
I:{to M}IMAP服务器返回适合以后使用URLFETCH检索的URLAUTH URL（有关语义和步骤的详细信息，请参阅[URLAUTH]）。
M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar"
M: A0054 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: A0054 OK GENURLAUTH completed
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: A0054 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 [BURL] for details of the semantics and steps). 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 2.4.1 for an example of submission where the third EHLO command/response is not present.
M:{to S}客户端连接到邮件提交服务器并启动新的邮件事务。它使用BURL指示SMTP提交服务器从IMAP服务器获取要发送的消息片段（有关语义和步骤的详细信息，请参阅[BURL]）。请注意，在成功执行STARTTLS命令之后，需要执行第二个EHLO命令。当且仅当第二个EHLO响应未列出任何BURL选项时，才需要第三个EHLO命令。第三个EHLO命令/响应不存在的提交示例见第2.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: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
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;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9
S: 250 2.5.0 OK
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--
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 [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获取要发送的消息片段（有关语义和步骤的详细信息，请参见[URLAUTH]）。所谓的“典当票”授权机制使用一个URI，该URI包含自己的授权凭证。
I: {to S} Returns the requested body parts.
I:{to S}返回请求的身体部位。
Mail submission server opens 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: a001 LOGIN submitserver secret
I: a001 OK submitserver logged in
S: a002 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...
S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: a003 OK Logout successful
I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
IMAP server ready
S: a001 LOGIN submitserver secret
I: a001 OK submitserver logged in
S: a002 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...
S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: a003 OK Logout successful
Note that if the IMAP server doesn't send CAPABILITY response code in the greeting, the mail submission server must issue the CAPABILITY command to learn about supported IMAP extensions as described in RFC 3501.
请注意，如果IMAP服务器未在问候语中发送功能响应代码，则邮件提交服务器必须发出CAPABILITY命令，以了解RFC 3501中所述的受支持的IMAP扩展。
Also, if data confidentiality is required, the mail submission server should start TLS before issuing the LOGIN command.
此外，如果需要数据保密性，邮件提交服务器应该在发出LOGIN命令之前启动TLS。
S: {to M} Submission server assembles the complete message, and 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: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 OK STORE completed
M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 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. The untagged FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword is described in Section 2.8.
注意：上面显示的UID STORE命令仅在标记的邮件位于当前所选邮箱中时有效；否则，它需要选择。此命令可以省略。未标记的获取响应是由[CONDSTORE]引起的。第2.8节介绍了$Forwarded IMAP关键字。
Lemonade-compliant IMAP servers MUST support IMAP4Rev1 [RFC3501], CATENATE [CATENATE], UIDPLUS [UIDPLUS], and URLAUTH [URLAUTH]. This support MUST be declared via CAPABILITY [RFC3501].
柠檬汁兼容的IMAP服务器必须支持IMAP4Rev1[RFC3501]、CATENATE[CATENATE]、UIDPLUS[UIDPLUS]和URLAUTH[URLAUTH]。此支持必须通过功能[RFC3501]声明。
Lemonade-compliant submit servers MUST support BURL [BURL], 8BITMIME [8BITMIME], BINARYMIME [CHUNKING], and CHUNKING [CHUNKING]. This support MUST be declared via EHLO [RFC2821]. BURL MUST support URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap" option following the BURL EHLO keyword (see [BURL] for more details).
Lemonade兼容的提交服务器必须支持BURL[BURL]、8BITMIME[8BITMIME]、BINARYMIME[CHUNKING]和CHUNKING[CHUNKING]。此支持必须通过EHLO[RFC2821]声明。BURL必须支持URLAUTH类型的URL[URLAUTH]，因此必须在BURL EHLO关键字后公布“imap”选项（有关详细信息，请参阅[BURL]）。
Additional normative statements are provided in other sections.
其他章节提供了其他规范性声明。
The so-called "pawn-ticket" authorization mechanism uses a URI, which contains its own authorization credentials using [URLAUTH]. The advantage of this mechanism is that the SMTP submit [SUBMIT] server cannot access any data on the [RFC3501] server without a "pawn-ticket" created by the client.
所谓的“典当票”授权机制使用一个URI，它使用[URLAUTH]包含自己的授权凭证。此机制的优点是，如果没有客户端创建的“当票”，SMTP submit[submit]服务器无法访问[RFC3501]服务器上的任何数据。
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 "file carbon copy" recipient. 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 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".
在传统策略中，MUA通过在单独的步骤中将消息写入fcc目的地，从而复制了传输到MSA所花费的精力。这可能是对本地磁盘文件的写入，也可能是对IMAP服务器上邮箱的附加。后者是代表“fcc问题”的“问题”方面的“重复网络数据传输”之一。
The [CATENATE] extension to [RFC3501] can be used to address the fcc problem. The final message is constructed in the mailbox designed for outgoing mail. Note that the [CATENATE] extension can only create a single message and only on the server that stages the outgoing message for submission. Additional copies of the message can be created on the same server using one or more COPY commands.
[RFC3501]的[CATENATE]扩展可用于解决fcc问题。最后一封邮件在为发送邮件而设计的邮箱中构建。请注意，[CATENATE]扩展只能创建一条消息，并且只能在将传出消息分段提交的服务器上创建。可以使用一个或多个复制命令在同一服务器上创建邮件的其他副本。
The $Forwarded IMAP keyword is used by several IMAP clients to specify that the message was resent 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-compliant servers 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。
Lemonade-compliant mail submission servers are expected to implement the following set of SMTP extensions to make message submission efficient.
Lemonade兼容的邮件提交服务器预计将实现以下SMTP扩展集，以提高邮件提交效率。
Lemonade clients should take advantage of these features.
柠檬水客户端应该利用这些特性。
Mobile clients regularly use networks with a relatively high latency. Avoidance of round-trips within a transaction has a great advantage for 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 [RFC2920].
移动客户端经常使用延迟相对较高的网络。避免事务中的往返对于减少带宽和总事务时间有很大的好处。因此，与柠檬水兼容的邮件提交服务器必须支持SMTP服务扩展以实现命令管道[RFC2920]。
Clients SHOULD pipeline SMTP commands when possible.
如果可能，客户端应通过管道发送SMTP命令。
Lemonade-compliant mail submission servers MUST support SMTP service extensions for delivery status notifications [RFC3461].
Lemonade兼容的邮件提交服务器必须支持SMTP服务扩展以发送状态通知[RFC3461]。
Lemonade-compliant mail submission servers MUST support the SMTP Service Extension for Message Size Declaration [RFC1870].
Lemonade兼容的邮件提交服务器必须支持SMTP服务扩展以进行邮件大小声明[RFC1870]。
Lemonade-compliant mail submission servers MUST "expand" all BURL parts before enforcing a message size limit.
柠檬水兼容的邮件提交服务器必须“扩展”所有BURL部分，然后才能强制执行邮件大小限制。
A Lemonade-compliant client SHOULD use message size declaration. In particular, it MUST NOT send a message to a mail submission server, if the client knows that the message exceeds the maximal message size advertised by the submission server.
柠檬水兼容的客户端应该使用消息大小声明。特别是，如果客户端知道消息超过了提交服务器公布的最大消息大小，则它不能向邮件提交服务器发送消息。
Lemonade-compliant mail submission servers MUST support SMTP Service Extension for Returning Enhanced Error Codes [RFC2034].
Lemonade兼容的邮件提交服务器必须支持SMTP服务扩展以返回增强的错误代码[RFC2034]。
Lemonade-compliant mail submission servers MUST support SMTP Service Extension for Secure SMTP over TLS [SMTP-TLS].
Lemonade兼容的邮件提交服务器必须支持SMTP服务扩展，以通过TLS[SMTP-TLS]实现安全SMTP。
Lemonade-compliant IMAP servers MUST support the CONDSTORE [CONDSTORE] extension. It allows a client to quickly resynchronize any mailbox by asking the server to return all flag changes that have occurred since the last known mailbox synchronization mark.
柠檬水兼容的IMAP服务器必须支持CONDSTORE[CONDSTORE]扩展。它允许客户端通过请求服务器返回自上次已知邮箱同步标记以来发生的所有标志更改来快速重新同步任何邮箱。
[IMAP-DISC] shows how to perform quick mailbox resynchronization.
[IMAP-DISC]显示如何执行快速邮箱重新同步。
Lemonade-compliant IMAP servers MUST support the NAMESPACE [NAMESPACE] extension. The extension allows clients to discover shared mailboxes and mailboxes belonging to other users.
Lemonade兼容的IMAP服务器必须支持命名空间[NAMESPACE]扩展。扩展允许客户端发现共享邮箱和属于其他用户的邮箱。
Lemonade-compliant IMAP servers MUST support the LITERAL+ [LITERAL+] extension. The extension allows clients to save a round-trip each time a non-synchronizing literal is sent.
Lemonade兼容的IMAP服务器必须支持LITERAL+[LITERAL+]扩展。该扩展允许客户端在每次发送非同步文本时保存一个往返。
Lemonade-compliant IMAP servers MUST support the IDLE [IDLE] extension. The extension allows clients to receive instant notifications about changes in the selected mailbox, without needing to poll for changes.
Lemonade兼容的IMAP服务器必须支持IDLE[IDLE]扩展。扩展允许客户端接收有关所选邮箱中更改的即时通知，而无需轮询更改。
Lemonade-compliant IMAP servers MUST support IMAP over TLS [RFC3501] as required by RFC 3501.
按照RFC 3501的要求，柠檬水兼容的IMAP服务器必须支持TLS[RFC3501]上的IMAP。
-----------------------------------------------------|
| Name of SMTP extension | Comment |
|-------------------------|--------------------------|
| PIPELINING | Section 3.1 |
|-------------------------|--------------------------|
| DSN | Section 3.2 |
|-------------------------|--------------------------|
| SIZE | Section 3.3 |
|-------------------------|--------------------------|
| ENHANCEDSTATUSCODES | Section 3.4 |
|-------------------------|--------------------------|
| STARTTLS | Section 3.5 |
|-------------------------|--------------------------|
| BURL | Forward without download,|
| | Section 2 |
|-------------------------|--------------------------|
| URLAUTH support in BURL | Section 2.5 |
|-------------------------|--------------------------|
| CHUNKING, | Section 2.5 |
| BINARYMIME | Section 2.5 |
|-------------------------|--------------------------|
| 8BITMIME, | Required by BURL |
|-------------------------|--------------------------|
| AUTH | Required by Submission, |
| | See [SMTPAUTH]. |
|-------------------------|--------------------------|
-----------------------------------------------------|
| Name of SMTP extension | Comment |
|-------------------------|--------------------------|
| PIPELINING | Section 3.1 |
|-------------------------|--------------------------|
| DSN | Section 3.2 |
|-------------------------|--------------------------|
| SIZE | Section 3.3 |
|-------------------------|--------------------------|
| ENHANCEDSTATUSCODES | Section 3.4 |
|-------------------------|--------------------------|
| STARTTLS | Section 3.5 |
|-------------------------|--------------------------|
| BURL | Forward without download,|
| | Section 2 |
|-------------------------|--------------------------|
| URLAUTH support in BURL | Section 2.5 |
|-------------------------|--------------------------|
| CHUNKING, | Section 2.5 |
| BINARYMIME | Section 2.5 |
|-------------------------|--------------------------|
| 8BITMIME, | Required by BURL |
|-------------------------|--------------------------|
| AUTH | Required by Submission, |
| | See [SMTPAUTH]. |
|-------------------------|--------------------------|
-----------------------------------------------------|
| Name of IMAP extension | Comment |
| or feature | |
|-------------------------|--------------------------|
| NAMESPACE | Section 5 |
|-------------------------|--------------------------|
| CONDSTORE | Section 4 |
|-------------------------|--------------------------|
| STARTTLS |Required by IMAP (RFC3501)|
|-------------------------|--------------------------|
| URLAUTH, | Forward without download,|
| CATENATE, | Section 2 |
| UIDPLUS | |
|-------------------------|--------------------------|
| LITERAL+ | Section 5 |
|-------------------------|--------------------------|
| IDLE | Section 5 |
|-------------------------|--------------------------|
| $Forwarded IMAP keyword | Section 2.8 |
|-------------------------|--------------------------|
-----------------------------------------------------|
| Name of IMAP extension | Comment |
| or feature | |
|-------------------------|--------------------------|
| NAMESPACE | Section 5 |
|-------------------------|--------------------------|
| CONDSTORE | Section 4 |
|-------------------------|--------------------------|
| STARTTLS |Required by IMAP (RFC3501)|
|-------------------------|--------------------------|
| URLAUTH, | Forward without download,|
| CATENATE, | Section 2 |
| UIDPLUS | |
|-------------------------|--------------------------|
| LITERAL+ | Section 5 |
|-------------------------|--------------------------|
| IDLE | Section 5 |
|-------------------------|--------------------------|
| $Forwarded IMAP keyword | Section 2.8 |
|-------------------------|--------------------------|
The Lemonade Working Group is looking into additional issues related to usage of email by mobile devices, possibly including:
柠檬水工作组正在研究与移动设备使用电子邮件有关的其他问题，可能包括：
- Media conversion (static and possibly streamed) - Transport optimization for low or costly bandwidth and less reliable mobile networks (e.g., quick reconnect) - Server to client notifications, possibly outside of the traditional IMAP band - Dealing with firewall and intermediaries - Compression and other bandwidth optimization - Filtering - Other considerations for mobile clients
- 媒体转换（静态和可能的流式）-针对低或昂贵带宽和不太可靠的移动网络的传输优化（例如，快速重新连接）-服务器到客户端通知，可能在传统IMAP频段之外—处理防火墙和中介—压缩和其他带宽优化—过滤—移动客户端的其他考虑事项
Security considerations on Lemonade "forward without download" are discussed throughout Section 2. Additional security considerations can be found in [RFC3501] and other documents describing other SMTP and IMAP extensions comprising the Lemonade profile.
关于柠檬水“无需下载就转发”的安全注意事项将在第2节中讨论。其他安全注意事项可以在[RFC3501]和其他文档中找到，这些文档描述了构成柠檬汁配置文件的其他SMTP和IMAP扩展。
Note that the mandatory-to-implement authentication mechanism for SMTP submission is described in [SUBMIT]. The mandatory-to-implement authentication mechanism for IMAP is described in [RFC3501].
请注意，在[SUBMIT]中描述了为SMTP提交实现身份验证机制的强制步骤。[RFC3501]中描述了为IMAP实现身份验证机制的强制要求。
When clients submit new messages, link protection such as TLS guards against an eavesdropper seeing the contents of the submitted message. It's 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, 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.
当客户端提交新消息时，链接保护（如TLS）可以防止窃听者看到提交消息的内容。然而，值得注意的是，即使不使用TLS，如果使用BURL引用文本，安全风险也不会比直接提交文本更大。如果未使用BURL，则窃听者可以访问消息的全文。如果使用了BURL，窃听者可能会也可能不会获得这种访问权，这取决于所使用的BURL的形式。例如，某些表单将URL的使用限制为授权为提交服务器的实体或特定用户。
When Lemonade clients use the BURL extension to mail submission, which 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 the mail submission path will provide protection against this attack.
当Lemonade客户端使用邮件提交的BURL扩展时，需要向邮件提交服务器发送URLAUTH令牌，应保护该令牌不被拦截，以避免可能向攻击者泄露消息内容的重播攻击。基于TLS的邮件提交路径加密将提供针对此攻击的保护。
Lemonade clients SHOULD use TLS-protected IMAP and mail submission channels when using BURL-based message submission to protect the URLAUTH token from interception.
Lemonade客户端在使用基于BURL的消息提交来保护URLAUTH令牌不被拦截时，应该使用TLS保护的IMAP和邮件提交通道。
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引用的内容时提供等效数据机密性的机制。
[BURL] Newman, C. "Message Submission BURL Extension", RFC 4468, May 2006.
[BURL]Newman，C.“邮件提交BURL扩展”，RFC 4468，2006年5月。
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[8BITMIME]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“8bit MIMEtransport的SMTP服务扩展”，RFC 16521994年7月。
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[CHUNKING]Vaudreuil，G.，“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 3030，2000年12月。
[CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
[CATENATE]Resnick，P.，“互联网消息访问协议（IMAP）CATENATE扩展”，RFC 4469，2006年4月。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[UIDPLUS]Crispin，M.，“互联网消息访问协议（IMAP）-UIDPLUS扩展”，RFC 4315，2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
2000年9月，SMTP扩展名为[C260，RFC]的命令被释放。
[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
[RFC1870]Klensin，J.，Freed，N.，和K.Moore，“邮件大小声明的SMTP服务扩展”，STD 10，RFC 1870，1995年11月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提交]Gellens，R.和J.Klensin，“邮件信息提交”，RFC 4409，2006年4月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，2002年2月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH]Crispin，M.，“互联网消息访问协议（IMAP）-URLAUTH扩展”，RFC 4467，2006年5月。
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC2034]Freed，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 20341996年10月。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[名称空间]Gahrns，M.和C.Newman，“IMAP4名称空间”，RFC 23421998年5月。
[SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTPAUTH]迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[LITERAL+]Myers，J.，“IMAP4非同步文字”，RFC2088，1997年1月。
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[CONDSTORE]Melnikov，A.和S.Hole，“条件存储操作或快速标志更改再同步的IMAP扩展”，RFC 45512006年6月。
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[IDLE]Leiba，B.，“IMAP4 IDLE命令”，RFC 2177，1997年6月。
[IMAP-DISC] Melnikov, A., "Synchronization operations for disconnected IMAP4 clients", Work in Progress, October 2004.
[IMAP-DISC]Melnikov，A.，“断开连接的IMAP4客户端的同步操作”，正在进行的工作，2004年10月。
This document is a product of Lemonade WG. The editors thank the Lemonade WG members that contributed comments and corrections; in particular: Randy Gellens, Dave Cridland, and Greg Vaudreuil.
本文件是柠檬水工作组的产品。编辑们感谢柠檬水工作组的成员们提供了评论和更正；特别是：兰迪·盖伦斯、戴夫·克里德兰和格雷格·沃德鲁伊。
This document borrows some text from "Message Submission" (February 2004) by Mark Crispin, as well as from the trio [BURL], [CATENATE], and [URLAUTH].
本文档借用了Mark Crispin的“消息提交”（2004年2月）以及[BURL]、[CATENATE]和[URLAUTH]三人的一些文字。
Authors' Addresses
作者地址
Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA
Stephane H.Maes甲骨文公司500甲骨文公园路M/S 4op634美国加利福尼亚州红木海岸94065
Phone: +1-650-607-6296
EMail: stephane.maes@oracle.com
Phone: +1-650-607-6296
EMail: stephane.maes@oracle.com
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode Limited TW12 2BX
EMail: Alexey.melnikov@isode.com
EMail: Alexey.melnikov@isode.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。