Independent Submission D. Wilson
Request for Comments: 8494 A. Melnikov, Ed.
Category: Informational Isode Ltd
ISSN: 2070-1721 November 2018
Independent Submission D. Wilson
Request for Comments: 8494 A. Melnikov, Ed.
Category: Informational Isode Ltd
ISSN: 2070-1721 November 2018
Multicast Email (MULE) over Allied Communications Publication (ACP) 142
通过联合通讯出版物（ACP）发送多播电子邮件（MULE）142
Abstract
摘要
Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (Multicast Email), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP 142). MULE enables transfer between Message Transfer Agents (MTAs). It doesn't provide a service similar to SMTP Submission (as described in RFC 6409).
Allied Communications Publication（ACP）142定义了P_MUL，这是一种适用于在UDP上运行的带宽受限和延迟确认（发射控制或“EMCON”）环境的可靠多播协议。本文档定义了MULE（多播电子邮件），这是一种用于通过P_MUL（如ACP 142中所定义）传输互联网邮件消息（如RFC 5322中所述）的应用协议。MULE支持邮件传输代理（MTA）之间的传输。它不提供类似于SMTP提交的服务（如RFC6409中所述）。
This document explains how MULE can be used in conjunction with SMTP (RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism.
本文档解释了MULE如何与SMTP（RFC 5321）结合使用，包括一些常见的SMTP扩展，以提供MTA到MTA的替代传输机制。
This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics.
这不是IETF规范；它描述了一个现有的实现。它的提供是为了促进可互操作的实现和第三方诊断。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8494.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8494.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. MULE ............................................................4
3.1. BSMTP-Like Payload Construction ............................6
3.2. Payload Compression ........................................7
3.3. Error Handling .............................................9
4. Gatewaying from Internet Mail to MULE ...........................9
4.1. Use of BDAT ...............................................10
5. Gatewaying from MULE to Internet Mail ..........................10
5.1. Handling of ESMTP Extensions and Errors ...................10
6. IANA Considerations ............................................11
6.1. Instructions for Designated Experts .......................11
6.2. SMTP Extension Support in MULE ............................12
7. Security Considerations ........................................14
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................17
Acknowledgements ..................................................19
Authors' Addresses ................................................19
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. MULE ............................................................4
3.1. BSMTP-Like Payload Construction ............................6
3.2. Payload Compression ........................................7
3.3. Error Handling .............................................9
4. Gatewaying from Internet Mail to MULE ...........................9
4.1. Use of BDAT ...............................................10
5. Gatewaying from MULE to Internet Mail ..........................10
5.1. Handling of ESMTP Extensions and Errors ...................10
6. IANA Considerations ............................................11
6.1. Instructions for Designated Experts .......................11
6.2. SMTP Extension Support in MULE ............................12
7. Security Considerations ........................................14
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................17
Acknowledgements ..................................................19
Authors' Addresses ................................................19
P_MUL [ACP142A] is a transport protocol for reliable multicast in bandwidth-constrained and delayed acknowledgement environments running on top of UDP. This document defines MULE, an application protocol for transferring Internet Mail messages [RFC5322] over ACP 142 P_MUL. The objectives of MULE are 1) to take advantage of the bandwidth-saving feature of using the multicast service as supported by modern computer networks and 2) to allow message transfer under EMCON (Emissions Control) conditions. EMCON or "radio silence" means that although receiving nodes are able to receive messages, they are not able to acknowledge the receipt of messages.
P_MUL[ACP142A]是一种传输协议，用于在UDP之上运行的带宽受限和延迟确认环境中进行可靠的多播。本文档定义了MULE，一种用于通过ACP142 P_MUL传输互联网邮件消息[RFC5322]的应用协议。MULE的目标是1）利用现代计算机网络支持的多播服务的带宽节约特性，2）允许在EMCON（排放控制）条件下进行消息传输。EMCON或“无线电静默”意味着尽管接收节点能够接收消息，但它们不能确认消息的接收。
The objective of this protocol is to take advantage of multicast communication for the transfer of messages between MTAs (Message Transfer Agents) on a single multicast network under normal (i.e., dialog-oriented) communication conditions and under EMCON conditions. An "EMCON condition" means that a receiving node is able to receive messages but cannot acknowledge the received messages for a relatively long time (hours or even days).
本协议的目的是利用多播通信，在正常（即面向对话）通信条件和EMCON条件下，在单个多播网络上的MTA（消息传输代理）之间传输消息。“EMCON条件”意味着接收节点能够接收消息，但在相对较长的时间（数小时甚至数天）内无法确认接收到的消息。
Figure 1 illustrates a simple multicast scenario, where the same message has to be sent from MTA A (through G/W) to MTA 1, MTA 2, MTA 3, and MTA 4.
图1演示了一个简单的多播场景，其中必须将相同的消息从MTA（通过G/W）发送到MTA 1、MTA 2、MTA 3和MTA 4。
+-------+ +-------+
| MTA 1 |<-\ /->| MTA 3 |
+-------+ +-----+ +-------+ \ +-------+ / +-------+
| MTA A |<--->| G/W |<---------------->| Router|<
+-------+ +-----+ +-------+ / +-------+ \ +-------+
| MTA 2 |<-/ \->| MTA 4 |
+-------+ +-------+
+-------+ +-------+
| MTA 1 |<-\ /->| MTA 3 |
+-------+ +-----+ +-------+ \ +-------+ / +-------+
| MTA A |<--->| G/W |<---------------->| Router|<
+-------+ +-----+ +-------+ / +-------+ \ +-------+
| MTA 2 |<-/ \->| MTA 4 |
+-------+ +-------+
|< -------------- MULE ---------------->|
|< -------------- MULE ---------------->|
Note: The gateway (G/W) and Router might or might not be running on the same system.
注意：网关（G/W）和路由器可能在同一系统上运行，也可能不在同一系统上运行。
Figure 1: Typical MULE Deployment
图1：典型的MULE部署
Due to multicast use (instead of a unicast communication service) in the above MTA configuration, only one message transmission from the gateway to the Router is required in order to reach MTA 1, MTA 2, MTA 3, and MTA 4, instead of four as required with unicast. This saves the transmission three message transactions and thus results in savings in bandwidth utilization. Depending on the network bandwidth
由于在上述MTA配置中使用了多播（而不是单播通信服务），因此只需从网关向路由器传输一次消息即可到达MTA 1、MTA 2、MTA 3和MTA 4，而不是单播所需的四次。这将节省三个消息事务的传输，从而节省带宽利用率。取决于网络带宽
(in some radio networks, it is less than 9.6 Kb/s), this savings can be of vital importance. The savings in bandwidth utilization become even greater with every additional receiving MTA.
（在某些无线网络中，它小于9.6 Kb/s），这一节省可能至关重要。每增加一个接收MTA，带宽利用率的节省就更大。
P_MUL employs a connectionless transport protocol to transmit messages. This guarantees reliable message transfer (through ACP 142 retransmissions) even in cases where one or more of the receiving MTAs are not able or allowed to acknowledge completely received messages for a certain period of time.
P_MUL采用无连接传输协议来传输消息。这保证了可靠的消息传输（通过ACP 142重传），即使在一个或多个接收MTA在一定时间段内不能或不允许确认完全接收到的消息的情况下也是如此。
This protocol specification requires fixed multicast groups and knowledge of the group memberships in one or more multicast groups of each participating node (MTA). Membership in multicast groups needs to be established before MULE messages can be sent.
此协议规范要求固定多播组以及了解每个参与节点（MTA）的一个或多个多播组中的组成员身份。在发送MULE消息之前，需要建立多播组中的成员身份。
MULE enables MTA-to-MTA transfer. It doesn't provide service similar to SMTP Submission [RFC6409].
MULE支持MTA到MTA的传输。它不提供类似于SMTP提交[RFC6409]的服务。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document also uses terminology from [RFC5321] and [RFC5598].
本文件还使用了[RFC5321]和[RFC5598]中的术语。
MULE is an electronic mail transport of Internet Mail messages [RFC5322] over an ACP 142 P_MUL network. It provides service similar to MTA-to-MTA SMTP [RFC5321]. This document doesn't define a service similar to SMTP Submission [RFC6409].
MULE是通过ACP142 P_MUL网络传输互联网邮件[RFC5322]的电子邮件。它提供类似于MTA到MTA SMTP[RFC5321]的服务。本文档未定义类似于SMTP提交[RFC6409]的服务。
An important feature of MULE is its capability to transport mail across multiple networks, referred to as "MULE mail relaying". A network consists of the nodes that are mutually accessible by ACP 142. Using MULE, a process can transfer mail to another process on the same ACP 142 network or to some other ACP 142 network via a relay or gateway process accessible to both networks.
MULE的一个重要特性是它能够跨多个网络传输邮件，称为“MULE邮件中继”。网络由可由ACP 142相互访问的节点组成。使用MULE，一个进程可以通过两个网络都可访问的中继或网关进程将邮件传送到同一ACP 142网络上的另一个进程，或传送到某个其他ACP 142网络。
MULE reuses the ESMTP extension framework defined in [RFC5321]. MULE servers MUST support the following ESMTP extensions: DSN [RFC3461], SIZE [RFC1870], 8BITMIME [RFC6152], MT-PRIORITY [RFC6710], DELIVERBY [RFC2852], BINARYMIME [RFC3030], and CHUNKING [RFC3030]. (As the
MULE重用[RFC5321]中定义的ESMTP扩展框架。MULE服务器必须支持以下ESMTP扩展：DSN[RFC3461]、大小[RFC1870]、8BITMIME[RFC6152]、MT-PRIORITY[RFC6710]、DeliveryBy[RFC2852]、二进制MIME[RFC3030]和分块[RFC3030]。（作为
message content size can always be determined from the compression wrapper and the size of the envelope, no special handling is needed for binary messages.)
消息内容大小始终可以通过压缩包装器和信封大小来确定，二进制消息不需要特殊处理。）
Relaying a message using MULE is performed as follows:
使用MULE中继消息的执行如下：
1. The message is reassembled from one or more DATA_PDUs [ACP142A].
1. 消息从一个或多个数据单元[ACP142A]重新组装。
2. If the contentType-ShortForm value is 25, the BSMTP-like payload is extracted from the compressedContent field and uncompressed (the reverse of the compression process specified in Section 3.2). If the contentType-ShortForm value is not 25, it is handled as described in [ACP142A]. This document doesn't further discuss any cases where the contentType-ShortForm value is not 25.
2. 如果contentType缩写值为25，则从compressedContent字段中提取类似BSMTP的有效负载并进行解压缩（与第3.2节中规定的压缩过程相反）。如果contentType缩写值不是25，则按照[ACP142A]中所述进行处理。本文档不进一步讨论contentType缩写值不是25的任何情况。
3. The list of recipients is extracted from RCPT-lines (see Section 3.1). If the receiving node is not responsible (directly or indirectly) for any of the recipients, the message is discarded and no further processing is done.
3. 收件人列表从RCPT行中提取（见第3.1节）。如果接收节点不对任何收件人负责（直接或间接），则丢弃消息，不再进行进一步处理。
4. The relay adds trace header fields, e.g., the Received header field. See [RFC7601] and Section 4.4 of [RFC5321].
4. 中继添加跟踪头字段，例如，接收头字段。参见[RFC7601]和[RFC5321]第4.4节。
5. The set of ACP 142 destinations for the message is created by extracting right-hand sides (hostnames) of each RCPT-line, eliminating duplicates, and then converting each hostname into the next ACP 142 destination using static configuration.
5. 通过提取每个RCPT行的右侧（主机名），消除重复，然后使用静态配置将每个主机名转换为下一个ACP 142目的地，创建消息的ACP 142目的地集。
6. For each unique ACP 142 destination, the following steps are performed:
6. 对于每个唯一的ACP 142目的地，执行以下步骤：
A. A new BSMTP-like payload is formed, as described in Section 3.1, that only contains RCPT-lines that correspond to recipients that can receive mail through the ACP 142 destination.
A.如第3.1节所述，形成一个新的类似BSMTP的有效载荷，该有效载荷仅包含对应于可通过ACP 142目的地接收邮件的收件人的RCPT行。
B. The created payload is compressed and encoded as specified in Section 3.2.
B.按照第3.2节的规定对创建的有效载荷进行压缩和编码。
C. The compressed payload is sent by P_MUL as a series of an Address_PDU and one or more DATA_PDUs. When the message has an associated MT-PRIORITY value [RFC6710], the MappedPriority(value) is included as the Priority field of the corresponding ACP 142 PDUs, including Address_PDUs, DATA_PDUs, and DISCARD_MESSAGE_PDUs. Here, MappedPriority(x) is defined as "6 - x".
C.压缩有效载荷由P_MUL作为一系列地址_PDU和一个或多个数据_PDU发送。当消息具有相关联的MT-PRIORITY值[RFC6710]时，MappedPriority（值）被包括为对应的ACP 142 pdu的优先级字段，包括地址pdu、数据pdu和丢弃消息pdu。这里，MappedPriority（x）被定义为“6-x”。
MULE uses a BSMTP-like payload that differs from Batch SMTP (BSMTP) [RFC2442] in that it eliminates unnecessary information. As with BSMTP, ESMTP capability negotiation is not used, since receiver EMCON restrictions prohibit such real-time interaction. For that reason, there is no point in including EHLO capabilities. "MAIL FROM:" and "RCPT TO:" prefixes are also excluded in order to save a few bytes.
MULE使用类似BSMTP的有效负载，这与批处理SMTP（BSMTP）[RFC2442]不同，因为它消除了不必要的信息。与BSMTP一样，不使用ESMTP能力协商，因为接收机EMCON限制禁止此类实时交互。因此，没有必要包括EHLO功能。“邮件发件人：”和“RCPT收件人：”前缀也被排除在外，以节省几个字节。
For each received message, the corresponding BSMTP-like payload is constructed as follows. Note that lines are terminated using CR LF.
对于每个接收到的消息，相应的类似BSMTP的有效载荷构造如下。请注意，使用CR LF终止线路。
1. The first line is what would be used for the data following "MAIL FROM:" in the SMTP dialog, i.e., it contains the return-path address (including the angle brackets -- "<" and ">") followed by any ESMTP extension parameters to the MAIL FROM command.
1. 第一行是SMTP对话框中“MAIL FROM:”后面的数据所使用的，即它包含返回路径地址（包括尖括号--“<”和“>”），后跟MAIL FROM命令的任何ESMTP扩展参数。
2. After that, there is a separate line for each recipient of the message. The value is what would follow "RCPT TO:" in the SMTP dialog, i.e., the recipient address (including the angle brackets -- "<" and ">") followed by any ESMTP extension parameters to the corresponding RCPT TO command.
2. 之后，邮件的每个收件人都有一行。该值是SMTP对话框中“RCPT TO:”后面的值，即收件人地址（包括尖括号--“<”和“>”），后跟相应RCPT TO命令的任何ESMTP扩展参数。
3. The list of recipients is terminated by an empty line (i.e., just CR LF).
3. 收件人列表以空行终止（即仅CR LF）。
4. The message content follows the empty line. There is no need for transparency ("dot stuffing") or terminating with a sequence "CR LF . CR LF", as the end of the message content is indicated by the end of the data (see Section 3.2 for more details).
4. 消息内容在空行后面。不需要透明（“点填充”）或以序列“CR-LF.CR-LF”终止，因为消息内容的结尾由数据的结尾表示（更多详细信息，请参见第3.2节）。
The following is an example of a BSMTP-like payload:
以下是类似BSMTP的有效负载示例：
<from@example.com> MT-PRIORITY=4 BODY=8BITMIME RET=HDRS ENVID=QQ314159
<to1@example.net> NOTIFY=FAILURE ORCPT=rfc822;Bob@ent.example.net
<to2@example.net> NOTIFY=SUCCESS,FAILURE
<from@example.com> MT-PRIORITY=4 BODY=8BITMIME RET=HDRS ENVID=QQ314159
<to1@example.net> NOTIFY=FAILURE ORCPT=rfc822;Bob@ent.example.net
<to2@example.net> NOTIFY=SUCCESS,FAILURE
From: from@example.com
To: To1 <to1@example.net>, To2 <to2@example.net>
Date: 27 Apr 2017 16:17 +0100
Subject: a test
MIME-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
From: from@example.com
To: To1 <to1@example.net>, To2 <to2@example.net>
Date: 27 Apr 2017 16:17 +0100
Subject: a test
MIME-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
This is worth <poundsign>100
这值100英镑
ABNF [RFC5234] for the BSMTP-like payload is:
BSMTP类有效载荷的ABNF[RFC5234]为：
bsmtp-like-payload = envelope CRLF payload envelope = FROM-line 1*RCPT-line FROM-line = reverse-path [SP mail-parameters] CRLF RCPT-line = forward-path [SP rcpt-parameters] CRLF
类似bsmtp的有效负载=信封CRLF有效负载信封=从第1行开始*从第1行开始的RCPT行=反向路径[SP邮件参数]CRLF RCPT行=正向路径[SP RCPT参数]CRLF
payload = *OCTET
; Conforms to message syntax as defined in RFC 5322
; and extended in MIME
payload = *OCTET
; Conforms to message syntax as defined in RFC 5322
; and extended in MIME
OCTET = <any 0-255 octet value>
reverse-path = <as defined in RFC 5321>
forward-path = <as defined in RFC 5321>
mail-parameters = <as defined in RFC 5321>
rcpt-parameters = <as defined in RFC 5321>
OCTET = <any 0-255 octet value>
reverse-path = <as defined in RFC 5321>
forward-path = <as defined in RFC 5321>
mail-parameters = <as defined in RFC 5321>
rcpt-parameters = <as defined in RFC 5321>
A BSMTP-like payload (Section 3.1) is first compressed using zlibCompress [RFC1950]. This compressed payload is placed in the compressedContent field of the CompressedContentInfo element defined in Section 4.2.6 of [STANAG-4406]. This is then encoded as BER encoding [ITU.X690.2002] of the CompressedData ASN.1 structure. For convenience, the original definition of the CompressedData ASN.1 structure is included below. The contentType-ShortForm value used by MULE MUST be 25. (The contentType-OID alternative is never used by MULE.)
首先使用zlibCompress[RFC1950]压缩类似BSMTP的有效载荷（第3.1节）。该压缩有效载荷位于[STANAG-4406]第4.2.6节中定义的CompressedContentInfo元素的compressedContent字段中。然后将其编码为CompressedData ASN.1结构的BER编码[ITU.X690.2002]。为方便起见，压缩数据ASN.1结构的原始定义包含在下面。MULE使用的contentType缩写值必须为25。（MULE从不使用contentType OID替代方案。）
The above procedure is similar to how X.400 messages are sent using Annex E of [STANAG-4406]. This makes it easier to implement MTAs that support both Internet messages and X.400 messages in the same code base.
上述程序类似于使用[STANAG-4406]附录E发送X.400消息的方式。这使得在同一代码库中实现同时支持Internet邮件和X.400邮件的MTA变得更加容易。
The Compressed Data Type (CDT) consists of content of any type that is compressed using a specified algorithm. The following object identifier identifies the CDT:
压缩数据类型（CDT）由使用指定算法压缩的任何类型的内容组成。以下对象标识符标识CDT：
id-mmhs-CDT ID ::= { iso(1) identified-organization(3) nato(26)
stanags(0) mmhs(4406) object-identifiers(0)
id-mcont(4) 2 }
id-mmhs-CDT ID ::= { iso(1) identified-organization(3) nato(26)
stanags(0) mmhs(4406) object-identifiers(0)
id-mcont(4) 2 }
The CDT is defined by the following ASN.1 type. Note that this definition is copied from [STANAG-4406] and is only reproduced here for the reader's convenience.
CDT由以下ASN.1类型定义。请注意，此定义是从[STANAG-4406]复制而来，此处仅为方便读者而复制。
DEFINITIONS ::=
BEGIN
CompressedData ::= SEQUENCE {
compressionAlgorithm CompressionAlgorithmIdentifier,
compressedContentInfo CompressedContentInfo
}
CompressionAlgorithmIdentifier ::= CHOICE {
algorithmID-ShortForm [0] AlgorithmID-ShortForm,
algorithmID-OID [1] OBJECT IDENTIFIER
}
AlgorithmID-ShortForm ::= INTEGER { zlibCompress (0) }
CompressedContentInfo ::= SEQUENCE {
CHOICE {
contentType-ShortForm [0] ContentType-ShortForm,
contentType-OID [1] OBJECT IDENTIFIER
},
compressedContent [0] EXPLICIT OCTET STRING
}
ContentType-ShortForm ::= INTEGER {
unidentified (0),
external (1), -- identified by the
-- object-identifier
-- of the EXTERNAL content
p1 (2),
p3 (3),
p7 (4)
}
END
DEFINITIONS ::=
BEGIN
CompressedData ::= SEQUENCE {
compressionAlgorithm CompressionAlgorithmIdentifier,
compressedContentInfo CompressedContentInfo
}
CompressionAlgorithmIdentifier ::= CHOICE {
algorithmID-ShortForm [0] AlgorithmID-ShortForm,
algorithmID-OID [1] OBJECT IDENTIFIER
}
AlgorithmID-ShortForm ::= INTEGER { zlibCompress (0) }
CompressedContentInfo ::= SEQUENCE {
CHOICE {
contentType-ShortForm [0] ContentType-ShortForm,
contentType-OID [1] OBJECT IDENTIFIER
},
compressedContent [0] EXPLICIT OCTET STRING
}
ContentType-ShortForm ::= INTEGER {
unidentified (0),
external (1), -- identified by the
-- object-identifier
-- of the EXTERNAL content
p1 (2),
p3 (3),
p7 (4)
}
END
This document effectively adds another enumeration choice to the ContentType-ShortForm definition. The updated definition looks like this:
本文档有效地向ContentType缩写定义添加了另一个枚举选项。更新后的定义如下所示：
ContentType-ShortForm ::= INTEGER {
unidentified (0),
external (1), -- identified by the
-- object-identifier
-- of the EXTERNAL content
p1 (2),
p3 (3),
p7 (4),
mule (25)
}
ContentType-ShortForm ::= INTEGER {
unidentified (0),
external (1), -- identified by the
-- object-identifier
-- of the EXTERNAL content
p1 (2),
p3 (3),
p7 (4),
mule (25)
}
MULE doesn't allow a next-hop Message Transfer Agent / Mail Delivery Agent (MTA/MDA) to return immediate Response Codes for the FROM-line or any of the recipients in the RCPT-line. Therefore, when MTAs/MDAs that are compliant with this specification receive a message that can't be relayed further or delivered, they MUST generate a non-delivery DSN report [RFC6522] message that includes the message/ delivery-status body part [RFC3464] and submit it using MULE to the FROM-line return-path address.
MULE不允许下一跳消息传输代理/邮件传递代理（MTA/MDA）返回发件人行或RCPT行中任何收件人的即时响应代码。因此，当符合此规范的MTA/MDA收到无法进一步中继或传递的邮件时，它们必须生成包含邮件/传递状态正文部分[RFC3464]的未传递DSN报告[RFC6522]邮件，并使用MULE将其提交到FROM行返回路径地址。
MULE relays (unlike MULE MDAs) don't need to verify that they understand all FROM-line and/or RCPT-line parameters. This keeps relay-only implementations simpler and avoids the need to upgrade them when MULE MDAs are updated to support extra SMTP extensions.
MULE继电器（与MULE MDA不同）不需要验证它们是否了解所有线路和/或RCPT线路参数。这使得仅中继实现更简单，并且避免了在更新MULE MDA以支持额外的SMTP扩展时升级它们的需要。
A gateway from Internet Mail to MULE acts as an SMTP server on the receiving side and as a MULE client on the sending side.
从Internet邮件到MULE的网关在接收端充当SMTP服务器，在发送端充当MULE客户端。
When the content type for a message is an Internet message content type (which may be 7-bit, 8-bit, or binary MIME), this is transported using ACP 142 [ACP142A] as follows:
当消息的内容类型是Internet消息内容类型（可以是7位、8位或二进制MIME）时，使用ACP 142[ACP142A]传输，如下所示：
1. For each mail message, a BSMTP-like payload is formed, as described in Section 3.1.
1. 如第3.1节所述，对于每个邮件消息，形成类似BSMTP的有效负载。
2. The created payload is compressed and encoded, as specified in Section 3.2.
2. 按照第3.2节的规定，对创建的有效载荷进行压缩和编码。
3. The compressed payload is sent by P_MUL as a series of an Address_PDU and one or more DATA_PDUs. When the message has an associated MT-PRIORITY value [RFC6710], the MappedPriority(value) is included as the Priority field of the corresponding ACP 142 PDUs, including Address_PDUs, DATA_PDUs, and DISCARD_MESSAGE_PDUs. Here, MappedPriority(x) is defined as "6 - x".
3. 压缩有效负载由P_MUL作为一系列地址_PDU和一个或多个数据_PDU发送。当消息具有相关联的MT-PRIORITY值[RFC6710]时，MappedPriority（值）被包括为对应的ACP 142 pdu的优先级字段，包括地址pdu、数据pdu和丢弃消息pdu。这里，MappedPriority（x）被定义为“6-x”。
The set of ACP 142 destinations for the message is derived from the next-hop MTAs for each of the recipients.
邮件的ACP 142目的地集源自每个收件人的下一跳MTA。
If a message is received by a gateway through SMTP transfers using the CHUNKING [RFC3030] extension, the message is rebuilt by the receiving MTA into its complete form and is then used as a single MULE message payload. Use of the BINARYMIME [RFC3030] extension is conveyed by inclusion of the BODY=BINARY parameter in the FROM-line.
如果网关使用分块[RFC3030]扩展通过SMTP传输接收到消息，则接收MTA会将该消息重新生成为其完整形式，然后将其用作单个MULE消息负载。BINARYMIME[RFC3030]扩展的使用是通过在FROM行中包含BODY=BINARY参数来实现的。
A gateway from MULE to Internet Mail acts as a MULE server on the receiving side and as an SMTP client on the sending side.
从MULE到Internet邮件的网关在接收端充当MULE服务器，在发送端充当SMTP客户端。
Gatewaying from an ACP 142 environment to Internet Email is the reverse of the process specified in Section 4.
从ACP 142环境到Internet电子邮件的网关连接与第4节中规定的过程相反。
1. The ACP 142 message is reassembled from one or more DATA_PDUs.
1. ACP 142消息从一个或多个数据pdu重新组装。
2. If the contentType-ShortForm value is 25, the BSMTP-like payload is extracted from the compressedContent field and uncompressed (the reverse of the compression process specified in Section 3.2). If the contentType-ShortForm value is not 25, it is handled as described in [ACP142A].
2. 如果contentType缩写值为25，则从compressedContent字段中提取类似BSMTP的有效负载并进行解压缩（与第3.2节中规定的压缩过程相反）。如果contentType缩写值不是25，则按照[ACP142A]中所述进行处理。
3. The BSMTP-like payload is converted to an SMTP transaction (see Section 3.1). (The first line of the BSMTP-like payload is prepended with "MAIL FROM:", and each following line (until the empty line is encountered) is prepended with "RCPT TO:". After skipping the empty delimiting line, the rest of the payload is the message body. This can be sent using either DATA or a series of BDAT commands, depending on the capabilities of the receiving SMTP system. For example, the presence of the BODY=BINARY parameter in the FROM-line would necessitate the use of BDAT or down-conversion of the message to 7-bit compatible representation.)
3. 类似BSMTP的有效负载被转换为SMTP事务（参见第3.1节）。（类似BSMTP的有效负载的第一行前面加上“邮件发件人：”，下面的每一行（直到遇到空行）前面加上“RCPT TO:”。跳过空分隔线后，剩余的有效负载是邮件正文。这可以使用数据或一系列BDAT命令发送，具体取决于接收SMTP系统的功能。例如，如果FROM行中存在body=BINARY参数，则需要使用BDAT或mes的下变频sage到7位兼容表示。）
ESMTP extension parameters to MAIL FROM and RCPT TO SMTP commands obtained from a BSMTP-like payload are processed according to specifications of the corresponding ESMTP extensions. This includes dealing with the absence of support for ESMTP extensions that correspond to MAIL FROM and RCPT TO parameters found in the BSMTP-like payload.
根据相应ESMTP扩展的规范，处理从类似BSMTP的有效负载获得的邮件发件人和RCPT to SMTP命令的ESMTP扩展参数。这包括处理缺少对ESMTP扩展的支持，这些扩展对应于类似BSMTP的有效负载中的MAIL-FROM和RCPT-to参数。
Failures to extract or uncompress BSMTP-like payloads should result in the receiver discarding such payloads.
未能提取或解压缩类似BSMTP的有效载荷应导致接收器丢弃此类有效载荷。
IANA has created a new "Multicast Email SMTP Extensions" registry under the "MAIL Parameters" registry. The registration procedure for this new registry is "Specification Required" [RFC8126]. The designated expert(s) will be appointed and managed by the editors of this document together with the Independent Submissions Editor. Selected designated expert(s) should (collectively) have a good knowledge of SMTP (and its extensions and extensibility mechanisms), as well as ACP 142 and its limitations. The subsections below provide more details: Section 6.1 specifies instructions for the designated expert(s), and Section 6.2 defines the initial content of the registry.
IANA在“邮件参数”注册表下创建了一个新的“多播电子邮件SMTP扩展”注册表。此新注册表的注册过程是“需要规范”[RFC8126]。指定专家将由本文件的编辑和独立提交文件的编辑共同任命和管理。选定的指定专家应（共同）充分了解SMTP（及其扩展和扩展机制），以及ACP 142及其局限性。以下小节提供了更多详细信息：第6.1节规定了指定专家的说明，第6.2节规定了登记册的初始内容。
The designated expert(s) for the new "Multicast Email SMTP Extensions" registry verifies that:
新“多播电子邮件SMTP扩展”注册表的指定专家验证：
1. The requested SMTP extension is already registered in the "SMTP Service Extensions" registry under the "MAIL Parameters" registry on the IANA website or is well documented on a stable, publicly accessible web page.
1. 请求的SMTP扩展已在IANA网站“邮件参数”注册表下的“SMTP服务扩展”注册表中注册，或者在稳定的、可公开访问的网页上有详细的文档记录。
2. The requested SMTP extension has the correct status as specified in Section 6.2. When deciding on status, the designated expert(s) is provided with the following guidelines:
2. 请求的SMTP扩展具有第6.2节中指定的正确状态。在决定地位时，指定专家将获得以下指南：
A. If the SMTP extension only affects commands other than MAIL FROM and RCPT TO, then the status should be "N/A".
A.如果SMTP扩展只影响除MAIL FROM和RCPT TO以外的命令，则状态应为“N/A”。
B. If the SMTP extension only applies to SMTP Submission [RFC6409] (and not to SMTP relay or final SMTP delivery), then the status should be "N/A".
B.如果SMTP扩展仅适用于SMTP提交[RFC6409]（而不适用于SMTP中继或最终SMTP传递），则状态应为“N/A”。
C. If the SMTP extension changes which commands are allowed during an SMTP transaction (e.g., if it adds commands alternative to DATA or declares commands other than MAIL FROM, RCPT TO, DATA, and BDAT to be a part of SMTP transaction), then the status should be "Disallowed" or "Special".
C.如果SMTP扩展在SMTP事务期间更改了允许的命令（例如，如果它添加了数据的替代命令，或声明除MAIL FROM、RCPT to、DATA和BDAT以外的命令是SMTP事务的一部分），则状态应为“不允许”或“特殊”。
D. If the SMTP extension adds extra round trips during SMTP transaction, then the status should be "Disallowed" or "Special".
D.如果SMTP扩展在SMTP事务期间添加额外的往返，则状态应为“不允许”或“特殊”。
Registration requests should include the SMTP extension name, status (see Section 6.2), and specification reference. They may also include an optional note.
注册请求应包括SMTP扩展名、状态（见第6.2节）和规范参考。它们还可能包括可选注释。
The following table summarizes how different SMTP extensions can be used with MULE. Each extension has one of the following statuses:
下表总结了MULE如何使用不同的SMTP扩展。每个扩展都具有以下状态之一：
o Required - support by MULE relays, SMTP-to-MULE gateway, or MULE-to-SMTP gateway is required.
o 必需-需要MULE中继、SMTP到MULE网关或MULE到SMTP网关的支持。
o Disallowed - incompatible with MULE.
o 不允许-与骡子不兼容。
o N/A - not relevant because the extension affects commands other than MAIL FROM and/or RCPT TO or is only defined for SMTP Submission [RFC6409]. Such extensions can still be used on the receiving SMTP side of an SMTP-to-MULE gateway.
o 不适用-不相关，因为扩展名影响来自和/或RCPT TO的邮件以外的命令，或者仅为SMTP提交定义[RFC6409]。这种扩展仍然可以在SMTP-to-MULE网关的接收SMTP端使用。
o Supported - can be used with MULE but requires bilateral agreement between sender and receiver.
o 支持-可与MULE一起使用，但需要发送方和接收方之间的双边协议。
o Special - needs to be accompanied by an explanation.
o 特殊-需要附有说明。
+------------------------+---------------+-----------+
| SMTP Extension Keyword | Status | Reference |
+------------------------+---------------+-----------+
| SIZE | Required | [RFC1870] |
| | | |
| 8BITMIME | Required | [RFC6152] |
| | | |
| DSN | Required | [RFC3461] |
| | | |
| MT-PRIORITY | Required | [RFC6710] |
| | | |
| DELIVERBY | Required | [RFC2852] |
| | | |
| BINARYMIME | Required | [RFC3030] |
| | | |
| CHUNKING | Special (*) | [RFC3030] |
| | | |
| ENHANCEDSTATUSCODES | Special (**) | [RFC2034] |
| | | |
| RRVS | Supported | [RFC7293] |
| | | |
| SUBMITTER | Supported | [RFC4405] |
| | | |
| PIPELINING | N/A | [RFC2920] |
| | | |
| STARTTLS | N/A | [RFC3207] |
| | | |
| AUTH | Special (***) | [RFC4954] |
| | | |
| BURL | N/A | [RFC4468] |
| | | |
| NO-SOLICITING | N/A | [RFC3865] |
| | | |
| CHECKPOINT | Disallowed | [RFC1845] |
| | | |
| CONNEG | Disallowed | [RFC4141] |
+------------------------+---------------+-----------+
+------------------------+---------------+-----------+
| SMTP Extension Keyword | Status | Reference |
+------------------------+---------------+-----------+
| SIZE | Required | [RFC1870] |
| | | |
| 8BITMIME | Required | [RFC6152] |
| | | |
| DSN | Required | [RFC3461] |
| | | |
| MT-PRIORITY | Required | [RFC6710] |
| | | |
| DELIVERBY | Required | [RFC2852] |
| | | |
| BINARYMIME | Required | [RFC3030] |
| | | |
| CHUNKING | Special (*) | [RFC3030] |
| | | |
| ENHANCEDSTATUSCODES | Special (**) | [RFC2034] |
| | | |
| RRVS | Supported | [RFC7293] |
| | | |
| SUBMITTER | Supported | [RFC4405] |
| | | |
| PIPELINING | N/A | [RFC2920] |
| | | |
| STARTTLS | N/A | [RFC3207] |
| | | |
| AUTH | Special (***) | [RFC4954] |
| | | |
| BURL | N/A | [RFC4468] |
| | | |
| NO-SOLICITING | N/A | [RFC3865] |
| | | |
| CHECKPOINT | Disallowed | [RFC1845] |
| | | |
| CONNEG | Disallowed | [RFC4141] |
+------------------------+---------------+-----------+
Table 1: Initial Content of Multicast Email SMTP Extensions Registry
表1：多播电子邮件SMTP扩展注册表的初始内容
(*) - SMTP CHUNKING MUST be supported on the receiving SMTP side of an SMTP-to-MULE gateway and MAY be used on the sending side of a MULE-to-SMTP gateway. A MULE relay doesn't need to do anything special for this extension.
（*）-SMTP到MULE网关的接收SMTP端必须支持SMTP分块，并且可以在MULE到SMTP网关的发送端使用SMTP分块。骡子接力器不需要为此扩展做任何特殊的事情。
(**) - The ENHANCEDSTATUSCODES extension is supported by including relevant status codes in DSN [RFC3461] reports.
（**）-通过在DSN[RFC3461]报告中包含相关状态代码来支持ENHANCEDSTATUSCODES扩展。
(***) - The AUTH parameter to the MAIL FROM command is "Supported",
but the rest of the AUTH extension is not applicable to MULE.
(***) - The AUTH parameter to the MAIL FROM command is "Supported",
but the rest of the AUTH extension is not applicable to MULE.
Note that the above table is not exhaustive. Future RFCs can define how SMTP extensions not listed above can be used in MULE.
请注意，上表并非详尽无遗。未来的RFC可以定义如何在MULE中使用上面未列出的SMTP扩展。
As MULE provides a service similar to SMTP, many of the security considerations from [RFC5321] apply to MULE as well; in particular, Sections 7.1, 7.2, 7.4, 7.6, 7.7, and 7.9 of [RFC5321] apply to MULE.
由于MULE提供类似于SMTP的服务，[RFC5321]中的许多安全注意事项也适用于MULE；具体而言，[RFC5321]第7.1、7.2、7.4、7.6、7.7和7.9节适用于MULE。
As MULE doesn't support capability negotiation or the SMTP HELP command, Section 7.5 of [RFC5321] ("Information Disclosure in Announcements") doesn't apply to MULE.
由于MULE不支持能力协商或SMTP帮助命令，[RFC5321]（“公告中的信息披露”）的第7.5节不适用于MULE。
As MULE doesn't support the VRFY or EXPN SMTP commands, Section 7.3 of [RFC5321] ("VRFY, EXPN, and Security"), which discusses email harvesting, doesn't apply to MULE.
由于MULE不支持VRFY或EXPN SMTP命令，[RFC5321]（“VRFY、EXPN和安全”）的第7.3节讨论电子邮件捕获，因此不适用于MULE。
Arguably, it is more difficult to cause an application-layer denial-of-service attack on a MULE server than on an SMTP server. This is partially due to the fact that ACP 142 is used in radio/wireless networks with relatively low bandwidth and very long round-trip time (especially if EMCON is in force). However, as MULE is using multicast, multiple MULE nodes can receive the same message and spend CPU resources processing it, even if the message is addressed to recipients that are not going to be handled by such nodes. As MULE lacks transport-layer source authentication, this can be abused by malicious senders.
可以说，在MULE服务器上引起应用层拒绝服务攻击比在SMTP服务器上更难。这部分是由于ACP 142用于具有相对较低带宽和很长往返时间的无线电/无线网络（尤其是在EMCON生效的情况下）。但是，由于MULE正在使用多播，多个MULE节点可以接收相同的消息并花费CPU资源来处理它，即使该消息是发送给这些节点不会处理的收件人的。由于MULE缺乏传输层源身份验证，因此恶意发送者可能会滥用此功能。
For security considerations related to use of zlib compression, see [RFC6713].
有关使用zlib压缩的安全注意事项，请参阅[RFC6713]。
Due to the multicast nature of MULE, it cannot use TLS or DTLS. Accordingly, it does not support STARTTLS [RFC3207]. Users should not depend on hop-by-hop confidentiality or integrity protection of mail transferred among MULE MTAs (in the same way they can't generally rely on the use of STARTTLS on SMTP MTA-to-MTA links) and should consider the use of end-to-end protection, such as S/MIME [RFC5750] [RFC5751].
由于MULE的多播特性，它不能使用TLS或DTL。因此，它不支持STARTTLS[RFC3207]。用户不应依赖于逐跳的机密性或完整性保护，在MULE MTAs之间传输的邮件（以同样的方式，他们一般不能依赖于SMTP MTA到MTA链路上的StuttLs的使用），并且应该考虑使用端到端保护，例如S/MIME [RCFC5050] [RCFC551 ]。
S/MIME signatures and/or encryption survive gatewaying between MULE and SMTP environments.
S/MIME签名和/或加密在MULE和SMTP环境之间的网关连接中仍然有效。
[ACP142A] CCEB, "P_Mul - A Protocol for Reliable Multicast in Bandwidth Constrained and Delayed Acknowledgement (EMCON) Environments", ACP 142(A), October 2008.
[ACP142A]CCEB，“P_Mul-带宽受限和延迟确认（EMCON）环境中的可靠多播协议”，ACP 142（A），2008年10月。
[ITU.X690.2002] ITU-T, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, August 2015.
[ITU.X690.2002]ITU-T，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，2015年8月。
[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, DOI 10.17487/RFC1870, November 1995, <https://www.rfc-editor.org/info/rfc1870>.
[RFC1870]Klensin，J.，Freed，N.，和K.Moore，“邮件大小声明的SMTP服务扩展”，STD 10，RFC 1870，DOI 10.17487/RFC1870，1995年11月<https://www.rfc-editor.org/info/rfc1870>.
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, DOI 10.17487/RFC1950, May 1996, <https://www.rfc-editor.org/info/rfc1950>.
[RFC1950]Deutsch，P.和J-L.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，DOI 10.17487/RFC1950，1996年5月<https://www.rfc-editor.org/info/rfc1950>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, DOI 10.17487/RFC2852, June 2000, <https://www.rfc-editor.org/info/rfc2852>.
[RFC2852]Newman，D.，“通过SMTP服务扩展交付”，RFC 2852，DOI 10.17487/RFC2852，2000年6月<https://www.rfc-editor.org/info/rfc2852>.
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, DOI 10.17487/RFC3030, December 2000, <https://www.rfc-editor.org/info/rfc3030>.
[RFC3030]Vaudreuil，G.，“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 3030，DOI 10.17487/RFC3030，2000年12月<https://www.rfc-editor.org/info/rfc3030>.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, <https://www.rfc-editor.org/info/rfc3461>.
[RFC3461]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，DOI 10.17487/RFC3461，2003年1月<https://www.rfc-editor.org/info/rfc3461>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, <https://www.rfc-editor.org/info/rfc3464>.
[RFC3464]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，DOI 10.17487/RFC3464，2003年1月<https://www.rfc-editor.org/info/rfc3464>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<https://www.rfc-editor.org/info/rfc5322>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <https://www.rfc-editor.org/info/rfc5598>.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC 5598，DOI 10.17487/RFC5598，2009年7月<https://www.rfc-editor.org/info/rfc5598>.
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, DOI 10.17487/RFC6152, March 2011, <https://www.rfc-editor.org/info/rfc6152>.
[RFC6152]Klensin，J.，Freed，N.，Rose，M.，和D.Crocker，Ed.，“8位MIME传输的SMTP服务扩展”，STD 71，RFC 6152，DOI 10.17487/RFC6152，2011年3月<https://www.rfc-editor.org/info/rfc6152>.
[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, <https://www.rfc-editor.org/info/rfc6522>.
[RFC6522]Kucherawy，M.，Ed.，“用于报告邮件系统管理消息的多部分/报告媒体类型”，STD 73，RFC 6522，DOI 10.17487/RFC6522，2012年1月<https://www.rfc-editor.org/info/rfc6522>.
[RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer Protocol Extension for Message Transfer Priorities", RFC 6710, DOI 10.17487/RFC6710, August 2012, <https://www.rfc-editor.org/info/rfc6710>.
[RFC6710]Melnikov，A.和K.Carlberg，“消息传输优先级的简单邮件传输协议扩展”，RFC 6710，DOI 10.17487/RFC6710，2012年8月<https://www.rfc-editor.org/info/rfc6710>.
[RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip' Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012, <https://www.rfc-editor.org/info/rfc6713>.
[RFC6713]Levine，J.，“应用程序/zlib”和“应用程序/gzip”媒体类型”，RFC 6713，DOI 10.17487/RFC6713，2012年8月<https://www.rfc-editor.org/info/rfc6713>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015, <https://www.rfc-editor.org/info/rfc7601>.
[RFC7601]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 7601，DOI 10.17487/RFC7601，2015年8月<https://www.rfc-editor.org/info/rfc7601>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[STANAG-4406] NATO, "Military Message Handling System", STANAG 4406 Ed. 2, March 2005.
[STANAG-4406]北约，“军事信息处理系统”，STANAG 4406版，2005年3月2日。
[RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, DOI 10.17487/RFC1845, September 1995, <https://www.rfc-editor.org/info/rfc1845>.
[RFC1845]Crocker，D.，Freed，N.，和A.Cargille，“检查点/重启的SMTP服务扩展”，RFC 1845，DOI 10.17487/RFC1845，1995年9月<https://www.rfc-editor.org/info/rfc1845>.
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 1996, <https://www.rfc-editor.org/info/rfc2034>.
[RFC2034]Freed，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 2034，DOI 10.17487/RFC2034，1996年10月<https://www.rfc-editor.org/info/rfc2034>.
[RFC2442] Freed, N., Newman, D., Belissent, J., and M. Hoy, "The Batch SMTP Media Type", RFC 2442, DOI 10.17487/RFC2442, November 1998, <https://www.rfc-editor.org/info/rfc2442>.
[RFC2442]Freed，N.，Newman，D.，Belissent，J.，和M.Hoy，“批量SMTP媒体类型”，RFC 2442，DOI 10.17487/RFC2442，1998年11月<https://www.rfc-editor.org/info/rfc2442>.
[RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, September 2000, <https://www.rfc-editor.org/info/rfc2920>.
[RFC2920]Freed，N.，“用于命令管道的SMTP服务扩展”，STD 60，RFC 2920，DOI 10.17487/RFC2920，2000年9月<https://www.rfc-editor.org/info/rfc2920>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，DOI 10.17487/RFC3207，2002年2月<https://www.rfc-editor.org/info/rfc3207>.
[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, DOI 10.17487/RFC3865, September 2004, <https://www.rfc-editor.org/info/rfc3865>.
[RFC3865]Malamud，C.，“无请求简单邮件传输协议（SMTP）服务扩展”，RFC 3865，DOI 10.17487/RFC3865，2004年9月<https://www.rfc-editor.org/info/rfc3865>.
[RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for Content Conversion", RFC 4141, DOI 10.17487/RFC4141, November 2005, <https://www.rfc-editor.org/info/rfc4141>.
[RFC4141]丰田章男，K.和D.克罗克，“用于内容转换的SMTP和MIME扩展”，RFC 4141DOI 10.17487/RFC4141，2005年11月<https://www.rfc-editor.org/info/rfc4141>.
[RFC4405] Allman, E. and H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message", RFC 4405, DOI 10.17487/RFC4405, April 2006, <https://www.rfc-editor.org/info/rfc4405>.
[RFC4405]Allman，E.和H.Katz，“用于指示电子邮件负责提交者的SMTP服务扩展”，RFC 4405，DOI 10.17487/RFC4405，2006年4月<https://www.rfc-editor.org/info/rfc4405>.
[RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, DOI 10.17487/RFC4468, May 2006, <https://www.rfc-editor.org/info/rfc4468>.
[RFC4468]Newman，C.，“消息提交BURL扩展”，RFC 4468，DOI 10.17487/RFC4468，2006年5月<https://www.rfc-editor.org/info/rfc4468>.
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, <https://www.rfc-editor.org/info/rfc4954>.
[RFC4954]Siemborski，R.，Ed.和A.Melnikov，Ed.，“用于身份验证的SMTP服务扩展”，RFC 4954，DOI 10.17487/RFC4954，2007年7月<https://www.rfc-editor.org/info/rfc4954>.
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, <https://www.rfc-editor.org/info/rfc5750>.
[RFC5750]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2证书处理”，RFC 5750，DOI 10.17487/RFC5750，2010年1月<https://www.rfc-editor.org/info/rfc5750>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<https://www.rfc-editor.org/info/rfc5751>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <https://www.rfc-editor.org/info/rfc6409>.
[RFC6409]Gellens，R.和J.Klensin，“邮件的邮件提交”，STD 72，RFC 6409，DOI 10.17487/RFC6409，2011年11月<https://www.rfc-editor.org/info/rfc6409>.
[RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid-Since Header Field and SMTP Service Extension", RFC 7293, DOI 10.17487/RFC7293, July 2014, <https://www.rfc-editor.org/info/rfc7293>.
[RFC7293]Mills，W.和M.Kucherawy，“要求收件人自标头字段和SMTP服务扩展起有效”，RFC 7293，DOI 10.17487/RFC7293，2014年7月<https://www.rfc-editor.org/info/rfc7293>.
Acknowledgements
致谢
Thank you to Steve Kille for suggestions, comments, and corrections on this document. An additional thank you goes to Barry Leiba, Sean Turner, Dave Crocker, and Nick Hudson for reviews and comments on this document.
感谢Steve Kille对本文档的建议、评论和更正。另外还要感谢巴里·莱巴、肖恩·特纳、戴夫·克罗克和尼克·哈德森对本文件的评论和评论。
Some text was borrowed from "P_Mul: An Application Protocol for the Transfer of Messages over Multicast Subnetworks and under EMCON Restrictions" (September 1997); we gratefully acknowledge the work of the authors of that document.
一些文本借用自“P_Mul：在多播子网和EMCON限制下传输消息的应用协议”（1997年9月）；我们感谢该文件作者的工作。
Authors' Addresses
作者地址
David Wilson Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
David Wilson Isode有限公司14 Castle Mews Hampton，米德尔塞克斯TW12 2NP英国
Email: David.Wilson@isode.com
Email: David.Wilson@isode.com
Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
Alexey Melnikov（编辑）Isode有限公司14 Castle Mews Hampton，米德尔塞克斯TW12 2NP英国
Email: Alexey.Melnikov@isode.com
Email: Alexey.Melnikov@isode.com