Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6710 Isode Ltd
Category: Standards Track K. Carlberg
ISSN: 2070-1721 G11
August 2012
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6710 Isode Ltd
Category: Standards Track K. Carlberg
ISSN: 2070-1721 G11
August 2012
Simple Mail Transfer Protocol Extension for Message Transfer Priorities
用于消息传输优先级的简单邮件传输协议扩展
Abstract
摘要
This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing.
此备忘录定义了SMTP（简单邮件传输协议）服务的扩展，其中为邮件提供了一个标签，以指示优先处理，从而使邮件处理节点能够将此信息考虑在内，以便进行后续处理。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6710.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6710.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Definition of the Priority SMTP Extension . . . . . . . . . . 4
4. Handling of Messages Received via SMTP . . . . . . . . . . . . 5
4.1. Handling of the MT-PRIORITY Parameter by the Receiving
SMTP Server . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Relay of Messages to Other Conforming SMTP/LMTP Servers . 6
4.3. Relay of Messages to Non-Conforming SMTP/LMTP Servers . . 7
4.4. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 7
4.5. Gatewaying a Message into a Foreign Environment . . . . . 7
4.6. Interaction with the DSN SMTP Extension . . . . . . . . . 7
5. The Priority Service Extension . . . . . . . . . . . . . . . . 8
5.1. Expedited Transfer . . . . . . . . . . . . . . . . . . . . 9
5.2. Timely Delivery . . . . . . . . . . . . . . . . . . . . . 10
6. Use of MT-PRIORITY with LMTP . . . . . . . . . . . . . . . . . 10
7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 14
9.1. Multiple MX Records . . . . . . . . . . . . . . . . . . . 14
9.2. Priority Assignment Policies . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. Requirements on Priority Assignment Policy
Registrations . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Initial Priority Assignment Policy Registrations . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Priority Assignment Policy for Military Messaging . . 22
Appendix B. Priority Assignment Policy for MIXER . . . . . . . . 23
Appendix C. Priority Assignment Policy for National Security
/ Emergency Preparedness (NS/EP) . . . . . . . . . . 24
Appendix D. Possible Implementation Strategies . . . . . . . . . 25
D.1. Probability . . . . . . . . . . . . . . . . . . . . . . . 25
D.2. Preemption of Sessions or Transactions . . . . . . . . . . 25
D.3. Resource Allocation Models . . . . . . . . . . . . . . . . 26
Appendix E. Background on Design Choices . . . . . . . . . . . . 26
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Definition of the Priority SMTP Extension . . . . . . . . . . 4
4. Handling of Messages Received via SMTP . . . . . . . . . . . . 5
4.1. Handling of the MT-PRIORITY Parameter by the Receiving
SMTP Server . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Relay of Messages to Other Conforming SMTP/LMTP Servers . 6
4.3. Relay of Messages to Non-Conforming SMTP/LMTP Servers . . 7
4.4. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 7
4.5. Gatewaying a Message into a Foreign Environment . . . . . 7
4.6. Interaction with the DSN SMTP Extension . . . . . . . . . 7
5. The Priority Service Extension . . . . . . . . . . . . . . . . 8
5.1. Expedited Transfer . . . . . . . . . . . . . . . . . . . . 9
5.2. Timely Delivery . . . . . . . . . . . . . . . . . . . . . 10
6. Use of MT-PRIORITY with LMTP . . . . . . . . . . . . . . . . . 10
7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 14
9.1. Multiple MX Records . . . . . . . . . . . . . . . . . . . 14
9.2. Priority Assignment Policies . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. Requirements on Priority Assignment Policy
Registrations . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Initial Priority Assignment Policy Registrations . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Priority Assignment Policy for Military Messaging . . 22
Appendix B. Priority Assignment Policy for MIXER . . . . . . . . 23
Appendix C. Priority Assignment Policy for National Security
/ Emergency Preparedness (NS/EP) . . . . . . . . . . 24
Appendix D. Possible Implementation Strategies . . . . . . . . . 25
D.1. Probability . . . . . . . . . . . . . . . . . . . . . . . 25
D.2. Preemption of Sessions or Transactions . . . . . . . . . . 25
D.3. Resource Allocation Models . . . . . . . . . . . . . . . . 26
Appendix E. Background on Design Choices . . . . . . . . . . . . 26
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Where resources for switching or transferring messages are constrained (e.g., bandwidth, round trip time, transition storage, or processing capability), it is desirable to give preferential handling to some messages over others, according to their labeled priority. This is particularly important during emergencies for first responders (Appendix C) and for environments such as military (Appendix A) and aviation (Appendix B) messaging, where messages have high operational significance, and the consequences of extraneous delay can be significant.
如果用于交换或传输消息的资源受到限制（例如，带宽、往返时间、转换存储或处理能力），则希望根据标记的优先级优先处理某些消息。这在紧急情况下对第一响应者（附录C）和军事（附录A）和航空（附录B）等环境尤其重要，因为在这些环境中，信息具有很高的操作重要性，并且外部延迟的后果可能非常严重。
In order for an SMTP receiver to be able to relay higher-priority messages first, there needs to be a mechanism to communicate (during both Message Submission [RFC6409] and Message Transfer [RFC5321]) the priority of each message. This specification defines this mechanism by specification of an SMTP [RFC5321] extension.
为了使SMTP接收器能够首先中继更高优先级的消息，需要有一种机制来通信（在消息提交[RFC6409]和消息传输[RFC5321]期间）每条消息的优先级。此规范通过SMTP[RFC5321]扩展规范定义此机制。
In order to permit end-to-end use of this extension across an email infrastructure that does not support it, a companion tunneling mechanism is defined in [PRIORITY-TUNNELING] that uses a new message header field [RFC5322].
为了允许在不支持此扩展的电子邮件基础结构中端到端地使用此扩展，在[PRIORITY-tunneling]中定义了一个附带的隧道机制，该机制使用新的消息头字段[RFC5322]。
This extension provides services to some classes of users in networks with limited available bandwidth or long round trip times, when the actual message transfer over the network can create a significant portion of the overall message delivery time from a sender to a recipient, for example, over a satellite or high-frequency radio link. It is also useful in case of a Mail Transfer Agent (MTA) queue buildup due to the rate of incoming messages being higher than the rate of outgoing messages. When neither of the two conditions mentioned above is true, the use of the MT-PRIORITY SMTP extension will not result in better SMTP service to any user. Also note that while this SMTP extension can help in improving delivery speed for higher-priority messages, it does not provide any guarantees that for two given messages with priorities M and N (M > N) submitted simultaneously, the message with priority M will arrive earlier than the message with priority N. That is, this extension calls for best effort to provide preferential processing.
当通过网络的实际消息传输可以创建从发送者到接收者（例如，通过卫星或高频无线电链路）的整个消息传递时间的很大一部分时，该扩展向具有有限可用带宽或长往返时间的网络中的某些类别的用户提供服务。由于传入邮件的速率高于传出邮件的速率，因此在邮件传输代理（MTA）队列累积的情况下，它也很有用。当上述两个条件均不成立时，使用MT-PRIORITY SMTP扩展不会为任何用户提供更好的SMTP服务。还请注意，虽然此SMTP扩展有助于提高高优先级邮件的传递速度，但它不能保证同时提交的两个优先级为M和N（M>N）的给定邮件，优先级为M的邮件将比优先级为N的邮件提前到达。也就是说，这一扩展要求尽最大努力提供优惠加工。
Besides the actions taken at the application level, it can thus be important to deploy priority or precedence mechanisms offered by the network itself to ensure timely delivery of the emails. Examples would be the use of DiffServ [RFC2474], RSVP [RFC2205], and [RFC6401] (an extension to RSVP that prioritizes reservations).
因此，除了在应用程序级别采取的操作外，部署网络本身提供的优先级或优先级机制以确保及时发送电子邮件也很重要。例如，使用DiffServ[RFC2474]、RSVP[RFC2205]和[RFC6401]（对RSVP的扩展，优先考虑保留）。
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] when they appear in ALL CAPS. These words also appear in this document in lower case as plain English words, absent their normative meanings.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”在所有大写字母中出现时，应按照[RFC2119]中的说明进行解释。这些词在本文件中也以小写形式出现，为普通英语单词，没有其规范意义。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation including the core rules defined in Appendix B of RFC 5234 [RFC5234].
形式语法使用增广的巴科斯诺尔形式（ABNF）[RFC5234]表示法，包括RFC 5234[RFC5234]附录B中定义的核心规则。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. Line breaks that do not start with a new "C:" or "S:" exist for editorial reasons and are not a part of the protocol.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。不以新“C:”或“S:”开头的换行符出于编辑原因而存在，不属于协议的一部分。
This document uses the term "priority" specifically in relation to the internal treatment of a message by the server. Messages with higher priorities may be given expedited handling, and those with lower priorities may be handled only as resources become available.
本文档使用术语“优先级”专门用于服务器对邮件的内部处理。优先级较高的邮件可能会得到快速处理，而优先级较低的邮件只能在资源可用时处理。
The Priority SMTP service extension is defined as follows:
优先级SMTP服务扩展的定义如下：
1. The textual name of this extension is "Priority Message Handling".
1. 此扩展的文本名称为“优先级消息处理”。
2. The EHLO keyword value associated with this extension is "MT-PRIORITY".
2. 与此扩展关联的EHLO关键字值为“MT-PRIORITY”。
3. The EHLO keyword has an OPTIONAL parameter that conveys the name of the Priority Assignment Policy (see Section 9.2) used by the server. (See the <mt-priority-ehlo> ABNF non-terminal in Section 7 for details of its syntax.) Absence of the parameter means that the server is unwilling to disclose its Priority Assignment Policy. Clients can choose to use the MT-PRIORITY SMTP extension even if they don't recognize a particular Priority Assignment Policy name advertised by a server.
3. EHLO关键字有一个可选参数，用于传递服务器使用的优先级分配策略的名称（参见第9.2节）。（有关其语法的详细信息，请参见第7节中的<mt priority ehlo>ABNF non terminal。）缺少该参数意味着服务器不愿意披露其优先级分配策略。客户端可以选择使用MT-PRIORITY SMTP扩展名，即使它们无法识别服务器播发的特定优先级分配策略名称。
4. No additional SMTP verbs are defined by this extension.
4. 此扩展未定义其他SMTP谓词。
5. One optional parameter ("MT-PRIORITY") is added to the MAIL FROM command. The value associated with this parameter is a decimal integer number from -9 to 9 (inclusive) indicating the priority of the email message (see Appendix E for more details on why this range was selected). The syntax of the MT-PRIORITY parameter is
5. 一个可选参数（“MT-PRIORITY”）添加到MAIL FROM命令中。与此参数关联的值是一个从-9到9（含9）的十进制整数，表示电子邮件的优先级（有关选择此范围的原因，请参阅附录E）。MT-PRIORITY参数的语法为
described by the <priority-value> ABNF non-terminal defined in Section 7. Higher numbers mean higher priority.
由第7节中定义的<priority value>ABNF非终端描述。数字越高，优先级越高。
6. The maximum length of a MAIL FROM command line is increased by 15 octets by the possible addition of a space, the MT-PRIORITY keyword, and a priority value.
6. 通过可能添加空格、MT-PRIORITY关键字和优先级值，来自命令行的邮件的最大长度增加了15个八位字节。
7. The MT-PRIORITY extension is valid for the submission service [RFC6409] and the Local Mail Transfer Protocol (LMTP) [RFC2033].
7. MT优先级扩展对提交服务[RFC6409]和本地邮件传输协议（LMTP）[RFC2033]有效。
This section describes how a conforming SMTP server should handle any messages received via SMTP.
本节介绍一致性SMTP服务器应如何处理通过SMTP接收的任何邮件。
The following rules apply to SMTP transactions in a server that supports the MT-PRIORITY parameter:
以下规则适用于支持MT-PRIORITY参数的服务器中的SMTP事务：
1. If any of the associated <esmtp-value>s (as defined in Section 4.1.2 of [RFC5321]) are not syntactically valid, or if there is more than one MT-PRIORITY parameter in a particular MAIL FROM command, the server MUST return an error, for example "501 syntax error in parameter" (with the 5.5.2 Enhanced Status Code [RFC2034] [RFC5248]).
1. 如果任何相关的<esmtp值>s（如[RFC5321]第4.1.2节中的定义）在语法上无效，或者如果特定的MAIL FROM命令中有多个MT-PRIORITY参数，则服务器必须返回错误，例如“参数中的501语法错误”（带有5.5.2增强状态代码[RFC2034][RFC5248]）。
2. When inserting a Received header field as specified in Section 4.4 of [RFC5321], the compliant MTA/MSA (Mail Submission Agent) SHOULD include the "PRIORITY" clause whose syntax is specified in Section 7.
2. 当按照[RFC5321]第4.4节的规定插入接收头字段时，符合要求的MTA/MSA（邮件提交代理）应包括“优先级”子句，其语法在第7节中有规定。
3. The received MT-PRIORITY parameter value SHOULD be logged as part of any logging of message transactions.
3. 收到的MT-PRIORITY参数值应作为任何消息事务记录的一部分进行记录。
4. If the sending SMTP client specified the MT-PRIORITY parameter to the MAIL FROM command, then the value of this parameter is the message priority.
4. 如果发送SMTP客户端为MAIL FROM命令指定了MT-PRIORITY参数，则此参数的值为消息优先级。
5. If no priority has been determined by the above, the server may use its normal policies to set the message's priority. By default, each message has priority 0.
5. 如果上面没有确定优先级，服务器可以使用其正常策略来设置消息的优先级。默认情况下，每条消息的优先级为0。
The SMTP server MUST NOT allow "upgraded" (positive) priorities from untrusted (e.g., unauthenticated) or unauthorized sources. (One example of an "unauthorized source" might be an SMTP sender that successfully authenticated using SMTP AUTH, but that is not explicitly authorized to use the SMTP MT-PRIORITY service. In case
SMTP服务器不得允许来自不受信任（如未经验证）或未经授权来源的“升级”（正）优先级。（一个“未经授权的源”的示例可能是使用SMTP AUTH成功进行身份验证，但未明确授权使用SMTP MT-PRIORITY服务的SMTP发件人。如果
of MTA-to-MTA transfer, such authorization will usually be done as a bilateral agreement between two domains to honor priorities from each other.) The server MAY, however, allow an untrusted source to lower its own message's priorities -- consider, for example, an email marketer that voluntarily sends its marketing messages at a negative priority.
在MTA到MTA传输中，这样的授权通常会作为两个域之间的双边协议来相互尊重优先级。但是，服务器可以允许不可信的源降低其自己的消息优先级——例如，考虑以负优先级自动发送其营销消息的电子邮件营销者。
The SMTP server MAY also alter the message priority (to lower or to raise it) in order to enforce some other site policy. (Note that this also includes the case in which the priority is not explicitly specified.) For example, an MSA might have a mapping table that assigns priorities to messages based on authentication credentials.
SMTP服务器还可以更改邮件优先级（降低或提高优先级），以强制执行其他一些站点策略。（请注意，这还包括未明确指定优先级的情况。）例如，MSA可能有一个映射表，该表根据身份验证凭据为消息分配优先级。
If the SMTP server changes (lowers or raises) the priority of a message, it SHOULD use the X.3.6 Enhanced Status Code [RFC2034] in its response to the MAIL FROM or in the final response to the DATA (or similar) command. The human readable text part after the status code contains the new priority, followed by SP (ASCII space) and explanatory human readable text.
如果SMTP服务器更改（降低或提高）邮件的优先级，则应在其对来自DATA（或类似）命令的邮件的响应或对DATA（或类似命令）的最终响应中使用X.3.6增强状态代码[RFC2034]。状态代码后的人类可读文本部分包含新的优先级，后跟SP（ASCII空格）和解释性人类可读文本。
Alternatively, an SMTP server that is an MSA MAY reject a message based on the determined priority. In such cases, the MSA SHOULD use the 450 or 550 reply code. The corresponding Enhanced Status Code MUST be X.7.15 [RFC2034] if the determined priority level is below the lowest priority currently acceptable for the receiving SMTP server. Note that this condition might be temporary. In some environments, operational policies might permit periods of operation that relay only higher-priority messages and reject lower priority ones. Such handling choices need to be specified for that operational environment.
或者，作为MSA的SMTP服务器可以基于确定的优先级拒绝邮件。在这种情况下，MSA应使用450或550回复代码。如果确定的优先级低于接收SMTP服务器当前可接受的最低优先级，则相应的增强状态代码必须为X.7.15[RFC2034]。请注意，这种情况可能是暂时的。在某些环境中，操作策略可能允许只中继高优先级消息而拒绝低优先级消息的操作周期。需要为该操作环境指定此类处理选项。
The following rules govern the behavior of a conforming MTA (in the role of an SMTP/LMTP client) when relaying a message that was received via the SMTP protocol to an SMTP/LMTP server that supports the MT-PRIORITY extension:
以下规则控制一致性MTA（作为SMTP/LMTP客户端）在将通过SMTP协议接收的邮件中继到支持MT-PRIORITY扩展的SMTP/LMTP服务器时的行为：
1. An MT-PRIORITY parameter with the value determined by the procedure from Section 4.1 MUST appear in the MAIL FROM command issued when the message is relayed to an MTA/MDA (Mail Delivery Agent) that also supports the MT-PRIORITY extension. (Note that due to site policy, this value might be different from the value received from the SMTP client. See Section 4.1 for details. Also note that this value might be different than the priority level at which the MTA actually handles the request, due to the rounding described in Section 5.)
1. 当邮件中继到也支持MT-PRIORITY扩展的MTA/MDA（邮件传递代理）时，必须在发出的MAIL from命令中显示MT-PRIORITY参数，该参数的值由第4.1节中的过程确定。（请注意，由于站点策略的原因，此值可能不同于从SMTP客户端接收的值。有关详细信息，请参阅第4.1节。还请注意，由于第5节中描述的舍入，此值可能不同于MTA实际处理请求的优先级。）
2. Further processing of the MT-PRIORITY parameter is described in Section 5.
2. MT-PRIORITY参数的进一步处理在第5节中描述。
The following rules govern the behavior of a conforming MTA (in the role of an SMTP/LMTP client) when relaying a message that was received via the SMTP protocol to an SMTP/LMTP server that does not support the MT-PRIORITY extension:
以下规则控制一致性MTA（以SMTP/LMTP客户端的角色）在将通过SMTP协议接收的邮件中继到不支持MT优先级扩展的SMTP/LMTP服务器时的行为：
1. The MTA relays the message without including the MT-PRIORITY parameter in the MAIL FROM command.
1. MTA中继消息，但不在MAIL FROM命令中包含MT-PRIORITY参数。
Several types of mechanisms exist to redirect or forward messages to alternative or multiple addresses [RFC5598]. Examples for this are aliases and mailing lists [RFC5321].
存在几种类型的机制将消息重定向或转发到备选或多个地址[RFC5598]。例如别名和邮件列表[RFC5321]。
If a message is subject to such processing, the Mediator node (Section 2.1 of [RFC5598]) SHOULD retain the MT-PRIORITY parameter value for all expanded and/or translated addresses.
如果消息受到此类处理，则中介节点（RFC5598第2.1节）应保留所有扩展和/或转换地址的MT-PRIORITY参数值。
The following rules govern the behavior of a conforming MTA when gatewaying a message that was received via the SMTP protocol into a foreign (non-SMTP) environment:
以下规则控制一致性MTA将通过SMTP协议接收的邮件网关传送到外部（非SMTP）环境时的行为：
1. If the destination environment is unable to provide an equivalent of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as if it is relaying to a non-conformant SMTP server (Section 4.3).
1. 如果目标环境无法提供MT-PRIORITY参数的等效值，则一致性MTA的行为应与中继到不一致性SMTP服务器的行为相同（第4.3节）。
2. If the destination environment is capable of providing an equivalent of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as if it is relaying to a conformant SMTP server (Section 4.2), converting the MT-PRIORITY value to the equivalent in the destination environment.
2. 如果目标环境能够提供MT-PRIORITY参数的等效值，则一致性MTA的行为应类似于中继到一致性SMTP服务器（第4.2节），将MT-PRIORITY值转换为目标环境中的等效值。
An MTA that needs to generate a delivery report (whether for successful delivery or delayed/failed delivery) for a message it is processing SHOULD use the priority value of the message as the priority of the generated delivery report. In particular, this requirement applies to MTAs that also implement [RFC3461].
需要为正在处理的邮件生成传递报告（无论是成功传递还是延迟/失败传递）的MTA应使用邮件的优先级值作为生成的传递报告的优先级。特别是，该要求适用于也实施[RFC3461]的MTA。
For delivery reports (DSNs) received by an MTA for relay, processing rules specified in Section 4.1 apply -- there is no special processing for relayed DSNs. It might seem tempting to try to detect DSNs and process them at an elevated priority under the assumption that failure notices need to get through quickly, even or perhaps especially if the DSN came from an untrusted source. But such a policy can create an exposure to fake DSN attacks by giving untrusted systems a way to inject high-priority messages. Implementation of such a policy also assumes that DSNs can be detected reliably, which may not be the case since some systems use nonstandard DSN formats.
对于MTA为中继接收的交付报告（DSN），第4.1节中规定的处理规则适用——对于中继DSN没有特殊处理。在假设故障通知需要快速传递的情况下，尝试检测DSN并以更高的优先级处理它们似乎很有诱惑力，甚至可能特别是当DSN来自不受信任的来源时。但是，这样的策略可以通过为不受信任的系统提供一种注入高优先级消息的方法，从而导致虚假DSN攻击的风险。这种策略的实现还假设可以可靠地检测DSN，但情况可能并非如此，因为某些系统使用非标准DSN格式。
The priorities of messages affect the order in which messages are transferred from the client to the server. This is largely independent from the order in which they were originally received by the server.
消息的优先级会影响消息从客户端传输到服务器的顺序。这在很大程度上与服务器最初接收它们的顺序无关。
A message priority is a decimal integer in the range from -9 to 9 (inclusive). SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), but they MUST implement all distinct priority levels specified in the Priority Assignment Policy (see Section 9.2) implemented by the server. That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported priority). For example, an implementation can treat priority values below and including -4 as priority -4, priority -3 as priority -2, and all priorities starting from 5 can be treated as priority 6. (See Section 9.2 for implementation/deployment considerations related to Priority Assignment Policy.)
消息优先级是介于-9到9（含9）之间的十进制整数。符合本规范的SMTP服务器不需要支持所有19个不同的优先级（即，将每个优先级值视为单独的优先级），但它们必须实现服务器实施的优先级分配策略（见第9.2节）中指定的所有不同优先级。也就是说，仅支持N个优先级级别（其中N<19）的实现将在内部将不支持的语法有效优先级值取整到下一个更高的支持数字（或最高支持优先级，如果该值高于任何支持的优先级）。例如，一个实现可以将低于并包括-4的优先级值视为优先级-4，将优先级-3视为优先级-2，并且从5开始的所有优先级都可以视为优先级6。（有关优先级分配政策的实施/部署注意事项，请参见第9.2节。）
Irrespective of the number of distinct priority levels supported by the SMTP server, when relaying the message to the next hop or delivering it over LMTP, the SMTP server MUST communicate the priority value as determined in Section 4.1.
无论SMTP服务器支持多少不同的优先级，在将消息中继到下一个跃点或通过LMTP传递消息时，SMTP服务器必须传递第4.1节中确定的优先级值。
Note: 19 possible priority levels are defined by this specification for extensibility. For example, a particular implementation or deployment environment might need to provide finer-grained control over message transfer priorities. See Appendix E for more details on why the range from -9 to 9 was selected.
注：本规范为扩展性定义了19种可能的优先级。例如，特定的实现或部署环境可能需要对消息传输优先级提供更细粒度的控制。有关选择-9到9范围的更多详细信息，请参见附录E。
As per the Priority Assignment Policy, some SMTP servers MAY impose additional maximum message size constraints for different message transfer priorities; for example, messages with priority 6 might not
根据优先级分配策略，某些SMTP服务器可能会对不同的邮件传输优先级施加额外的最大邮件大小限制；例如，优先级为6的消息可能不会
be larger than 4 Kb. If an SMTP server chooses to reject a message because it is too big for the determined priority, it SHOULD use 552 reply codes together with the X.7.16 Enhanced Status Code [RFC2034].
大于4KB。如果SMTP服务器选择拒绝邮件，因为该邮件对于确定的优先级来说太大，它应该使用552个回复代码以及X.7.16增强状态代码[RFC2034]。
Implementation Note: If the SMTP server also supports the SMTP SIZE extension [RFC1870], then an SMTP client can use both SIZE= and MT-PRIORITY= parameters on the MAIL FROM command. This allows the server to perform early rejection of a message in case the message size is too big for the specified priority, thus avoiding wasting bandwidth by transferring the message first and then rejecting it due to its size.
实施说明：如果SMTP服务器还支持SMTP大小扩展[RFC1870]，则SMTP客户端可以在MAIL FROM命令上同时使用SIZE=和MT-PRIORITY=参数。这允许服务器在消息大小对于指定优先级太大的情况下提前拒绝消息，从而避免通过先传输消息，然后根据消息大小拒绝消息而浪费带宽。
The Priority Service Extension can be combined with the DELIVERBY [RFC2852] SMTP service extension; however, there is no requirement that both extensions always be implemented together.
优先级服务扩展可以与DELIVERBY[RFC2852]SMTP服务扩展结合使用；但是，并不要求两个扩展总是一起实现。
The main service provided by the Priority Message Handling SMTP Service Extension is expedited transfer of emails with a higher priority. Therefore, an SMTP client that has more than one email to send at a given time sends those with a higher priority before those with a lower one. Additionally, the retry interval and/or default timeout before a non-delivery report is generated MAY be lower (more aggressive) for messages of higher priority. Lower retry intervals/ default timeouts are controlled by the local MTA policy.
“优先邮件处理SMTP服务”扩展提供的主要服务是加快优先级较高的电子邮件的传输。因此，在给定时间有多封电子邮件要发送的SMTP客户端会先发送优先级较高的邮件，再发送优先级较低的邮件。此外，对于优先级较高的邮件，在生成未送达报告之前的重试间隔和/或默认超时可能较低（更激进）。较低的重试间隔/默认超时由本地MTA策略控制。
Note that as this SMTP extension requires some sort of trust relationship between a sender and a receiver and thus some form of authentication (whether using SMTP AUTH, TLS, IP address whitelist, etc.), so senders using this SMTP extension will not be subject to greylisting [RFC6647], unless they are unauthorized to use this SMTP extension due to an explicit policy decision or a misconfiguration error. However, note that in case of connection-level or SMTP EHLO/ HELO greylisting, SMTP AUTH or TLS authentication options are not available to the server.
请注意，由于此SMTP扩展需要发送者和接收者之间的某种信任关系以及某种形式的身份验证（无论是否使用SMTP身份验证、TLS、IP地址白名单等），因此使用此SMTP扩展的发送者将不受灰色列表[RFC6647]的约束，除非他们由于明确的策略决定或错误配置而未经授权使用此SMTP扩展。但是，请注意，在连接级别或SMTP EHLO/HELO灰色列表的情况下，服务器无法使用SMTP验证或TLS验证选项。
In order to make implementations of this extension easier, this SMTP extension only allows a single priority for all recipients of the same message.
为了简化此扩展的实现，此SMTP扩展只允许同一邮件的所有收件人具有单一优先级。
Within a priority level, the MTA uses its normal algorithm (the algorithm used in absence of this SMTP extension) for determining message processing order.
在优先级级别内，MTA使用其正常算法（在没有此SMTP扩展时使用的算法）来确定邮件处理顺序。
Several possible ways of implementing expedited transfer are described in more details in Appendix D. Note that these sections don't describe all details and pitfalls for each implementation strategy.
附录D更详细地描述了几种可能的实施快速转移的方法。请注意，这些章节并未描述每种实施策略的所有细节和陷阱。
An important constraint (usually associated with higher-priority levels) in some environments is that messages with high-priority values have some delivery time constraints. In some cases, higher priorities mean a shorter maximum time allowed for delivery.
在某些环境中，一个重要的约束（通常与更高的优先级相关）是具有高优先级值的消息具有一些传递时间约束。在某些情况下，更高的优先级意味着允许交付的最长时间更短。
Unextended SMTP does not offer a service for timely delivery, i.e., "deliver this message within X seconds from submission" service. The "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in [RFC2852] is an example of an SMTP extension providing a service that can be used to implement timely delivery. Note that SMTP DELIVERBY and SMTP MT-PRIORITY extensions are complimentary and can be used together (assuming the SMTP server they are talking to advertises support for both). However, note that use of the DELIVERBY extension alone does not guarantee any priority processing. If the client is using both SMTP DELIVERBY and SMTP MT-PRIORITY at the same time, the client can consider using smaller DELIVERBY timeouts for higher-priority messages.
未扩展SMTP不提供及时传递服务，即“在提交后X秒内传递此邮件”服务。[RFC2852]中定义的“通过SMTP服务扩展传递”（delivery By Extension）是SMTP扩展的一个示例，该扩展提供了可用于实现及时传递的服务。请注意，SMTP DELIVERBY和SMTP MT-PRIORITY扩展是互为补充的，可以一起使用（假设与它们交谈的SMTP服务器广告了对两者的支持）。但是，请注意，仅使用DELIVERBY扩展并不能保证任何优先级处理。如果客户端同时使用SMTP交付和SMTP MTT优先级，则客户端可以考虑使用较小的递送超时来获得更高优先级的消息。
An LMTP server can advertise support for the MT-PRIORITY extension if it supports any combination of the following features:
如果LMTP服务器支持以下功能的任意组合，则可以公布对MT-PRIORITY扩展的支持：
1. The LMTP server is architected in such a way that it can deliver higher-priority messages quicker than lower-priority messages.
1. LMTP服务器的架构使其能够比低优先级消息更快地交付高优先级消息。
2. The LMTP server logs that the MT-PRIORITY extension was used by the previous SMTP hop.
2. LMTP服务器记录上一个SMTP跃点使用了MT优先级扩展。
3. The LMTP server is exposing information about the MT-PRIORITY extension to a delivery-time filtering engine such as Sieve [RFC5228].
3. LMTP服务器正在将有关MT优先级扩展的信息公开给传递时间过滤引擎，如SIVE[RFC5228]。
priority-value = (["-"] NZDIGIT) / "0"
; Allowed values are from -9 to 9 inclusive
priority-value = (["-"] NZDIGIT) / "0"
; Allowed values are from -9 to 9 inclusive
NZDIGIT = %x31-39
; "1"-"9"
NZDIGIT = %x31-39
; "1"-"9"
CFWS = <defined in RFC 5322>
CFWS = <defined in RFC 5322>
; New "clause" that can be used in the Received header field
Pri = CFWS "PRIORITY" FWS priority-value
; Complies with the <Additional-Registered-Clauses>
; non-terminal syntax from RFC 5321.
; New "clause" that can be used in the Received header field
Pri = CFWS "PRIORITY" FWS priority-value
; Complies with the <Additional-Registered-Clauses>
; non-terminal syntax from RFC 5321.
mt-priority-ehlo = "MT-PRIORITY" [SP priority-profile] ; Complies with the <ehlo-line> ABNF production ; from RFC 5321.
mt优先级ehlo=“mt-priority”[SP优先级配置文件]；符合ABNF生产的<ehlo生产线>；来自RFC5321。
priority-profile = 1*20(ALPHA / DIGIT / "-" / "_" / ".")
; name of the Priority Assignment Profile advertized in
; the MT-PRIORITY EHLO response.
priority-profile = 1*20(ALPHA / DIGIT / "-" / "_" / ".")
; name of the Priority Assignment Profile advertized in
; the MT-PRIORITY EHLO response.
ALPHA = <Defined in RFC 5234>
ALPHA = <Defined in RFC 5234>
DIGIT = <Defined in RFC 5234>
DIGIT = <Defined in RFC 5234>
The original submission (from MUA (Mail User Agent) to MSA) might appear as shown below. Note that the example is also making use of the STARTTLS [RFC3207], DELIVERBY [RFC2852], and DSN [RFC3461] SMTP extensions, even though there is no requirement that these other extensions be supported when the MT-PRIORITY SMTP extension is implemented.
原始提交（从MUA（邮件用户代理）到MSA）可能如下所示。注意，该示例还使用了STARTTLS[RFC3207]、deliveryby[RFC2852]和DSN[RFC3461]SMTP扩展，即使在实现MT-PRIORITY SMTP扩展时不要求支持这些其他扩展。
S: 220 example.com SMTP server here
C: EHLO mua.example.com
S: 250-example.com
S: 250-STARTTLS
S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5
S: 250-DSN
S: 250-DELIVERBY
S: 250-ENHANCEDSTATUSCODES
S: 250 MT-PRIORITY MIXER
C: AUTH SCRAM-SHA-1
[...authentication exchange...]
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<eljefe@example.com> BY=125;R ENVID=QQ314159
MT-PRIORITY=3
S: 250 2.1.0 <eljefe@example.com> sender ok
C: RCPT TO:<topbanana@example.net>
S: 250 2.1.5 <topbanana@example.net> recipient ok
C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
ORCPT=rfc822;Dana@Ivory.example.net
S: 250 2.1.5 <Dana@Ivory.example.net> recipient ok
C: DATA
S: 354 okay, send message
C: (message goes here)
C: .
S: 250 2.1.0 message accepted
C: QUIT
S: 221 2.0.0 goodbye
S: 220 example.com SMTP server here
C: EHLO mua.example.com
S: 250-example.com
S: 250-STARTTLS
S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5
S: 250-DSN
S: 250-DELIVERBY
S: 250-ENHANCEDSTATUSCODES
S: 250 MT-PRIORITY MIXER
C: AUTH SCRAM-SHA-1
[...authentication exchange...]
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<eljefe@example.com> BY=125;R ENVID=QQ314159
MT-PRIORITY=3
S: 250 2.1.0 <eljefe@example.com> sender ok
C: RCPT TO:<topbanana@example.net>
S: 250 2.1.5 <topbanana@example.net> recipient ok
C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
ORCPT=rfc822;Dana@Ivory.example.net
S: 250 2.1.5 <Dana@Ivory.example.net> recipient ok
C: DATA
S: 354 okay, send message
C: (message goes here)
C: .
S: 250 2.1.0 message accepted
C: QUIT
S: 221 2.0.0 goodbye
In the above example, the MUA has specified the priority 3 and the server has accepted it. The server is advertising the MIXER Priority Assignment Policy (the default). Another variant of the initial submission might look like:
在上面的示例中，MUA已指定优先级3，服务器已接受该优先级。服务器正在公布混音器优先级分配策略（默认）。初始提交的另一个变体可能如下所示：
S: 220 example.com SMTP server here
C: EHLO mua.example.com
S: 250-example.com
S: 250-STARTTLS
S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5
S: 250-DSN
S: 250-DELIVERBY
S: 250-ENHANCEDSTATUSCODES
S: 250 MT-PRIORITY
C: AUTH SCRAM-SHA-1
[...authentication exchange...]
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<eljefe@example.com> BY=125;R ENVID=QQ314159
S: 250 2.1.0 <eljefe@example.com> sender ok
C: RCPT TO:<topbanana@example.net>
S: 250 2.1.5 <topbanana@example.net> recipient ok
C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
ORCPT=rfc822;Dana@Ivory.example.net
S: 250 2.1.5 <Dana@Ivory.example.net> recipient ok
C: DATA
S: 354 okay, send message
C: (message goes here)
C: .
S: 250 X.3.6 3 is the new priority assigned to the message
C: QUIT
S: 221 2.0.0 goodbye
S: 220 example.com SMTP server here
C: EHLO mua.example.com
S: 250-example.com
S: 250-STARTTLS
S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5
S: 250-DSN
S: 250-DELIVERBY
S: 250-ENHANCEDSTATUSCODES
S: 250 MT-PRIORITY
C: AUTH SCRAM-SHA-1
[...authentication exchange...]
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<eljefe@example.com> BY=125;R ENVID=QQ314159
S: 250 2.1.0 <eljefe@example.com> sender ok
C: RCPT TO:<topbanana@example.net>
S: 250 2.1.5 <topbanana@example.net> recipient ok
C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
ORCPT=rfc822;Dana@Ivory.example.net
S: 250 2.1.5 <Dana@Ivory.example.net> recipient ok
C: DATA
S: 354 okay, send message
C: (message goes here)
C: .
S: 250 X.3.6 3 is the new priority assigned to the message
C: QUIT
S: 221 2.0.0 goodbye
In the above example, the MUA has not specified any priority, but the MSA has assigned priority 3 to the message. Also note that the server is unwilling to adverte the Priority Assignment Policy it supports in the EHLO response.
在上述示例中，MUA未指定任何优先级，但MSA已将优先级3分配给消息。还请注意，服务器不愿意在EHLO响应中通告它支持的优先级分配策略。
The MSA relays the message to the next MTA.
MSA将消息转发给下一个MTA。
S: 220 example.net SMTP server here
C: EHLO example.com
S: 250-example.net
S: 250-DSN
S: 250-DELIVERBY
S: 250 MT-PRIORITY STANAG4406
C: MAIL FROM:<eljefe@example.com> BY=120;R ENVID=QQ314159
MT-PRIORITY=3
S: 250 <eljefe@example.com> sender ok
C: RCPT TO:<topbanana@example.net>
S: 250 <topbanana@example.net> recipient ok
C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
ORCPT=rfc822;Dana@Ivory.example.net
S: 250 <Dana@Ivory.example.net> recipient ok
C: DATA
S: 354 okay, send message
C: (message goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
S: 220 example.net SMTP server here
C: EHLO example.com
S: 250-example.net
S: 250-DSN
S: 250-DELIVERBY
S: 250 MT-PRIORITY STANAG4406
C: MAIL FROM:<eljefe@example.com> BY=120;R ENVID=QQ314159
MT-PRIORITY=3
S: 250 <eljefe@example.com> sender ok
C: RCPT TO:<topbanana@example.net>
S: 250 <topbanana@example.net> recipient ok
C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
ORCPT=rfc822;Dana@Ivory.example.net
S: 250 <Dana@Ivory.example.net> recipient ok
C: DATA
S: 354 okay, send message
C: (message goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
The receiving SMTP server advertises support for the "STANAG4406" Priority Assignment Policy, which supports 6 priority levels as described in Appendix A. This means that the server will use the priority value 4 internally (the next supported priority higher or equal to 3) and will communicate the priority value 3 when relaying it to the next hop (if necessary).
接收SMTP服务器播发对“STANAG4406”优先级分配策略的支持，该策略支持附录A中所述的6个优先级。这意味着服务器将在内部使用优先级值4（下一个支持的优先级更高或等于3），并在将优先级值3中继到下一个跃点时进行通信（如有必要）。
If multiple DNS MX records are used to specify multiple servers for a domain in Section 5 of [RFC5321], it is strongly advised that all of them support the MT-PRIORITY extension and handle priorities in exactly the same way. If one or more servers behave differently in this respect, then it is strongly suggested that none of the servers support the MT-PRIORITY extension. Otherwise, unexpected differences in message delivery speed or even rejections can happen during temporary or permanent failures, which users might perceive as serious reliability issues.
如果使用多个DNS MX记录为[RFC5321]第5节中的域指定多个服务器，强烈建议所有服务器都支持MT-PRIORITY扩展，并以完全相同的方式处理优先级。如果一个或多个服务器在这方面表现不同，则强烈建议所有服务器都不支持MT-PRIORITY扩展。否则，在临时或永久故障期间，可能会出现消息传递速度的意外差异，甚至拒绝，用户可能会认为这是严重的可靠性问题。
This document allows up to 19 distinct priority values. In a particular operating environment, independent originators need to assign priority values according to, roughly, the same criteria, so that the same "high priority message" doesn't get associated with the value 3 for one sender and with the value 5 for another, as such messages might unintentionally receive different preferential treatment.
此文档最多允许19个不同的优先级值。在特定的操作环境中，独立发起者需要根据大致相同的标准分配优先级值，以便相同的“高优先级消息”不会与一个发送者的值3和另一个发送者的值5相关联，因为这样的消息可能会无意中获得不同的优惠待遇。
In order to achieve consistent behavior in an operating environment, the Priority Assignment Policy (together with possible associated restrictions on maximum message sizes for each priority (if any), default timeouts, etc.) should be documented for the environment. Each SMTP/LMTP server supports a Priority Assignment Policy, whether explicit (advertised in the MT-PRIORITY EHLO response) or implicit (not advertised). The default Priority Assignment Policy (assumed by the client when no Priority Assignment Policy name is advertised in the MT-PRIORITY EHLO response) is specified in Appendix B. Two other policies are specified in Appendix A and Appendix C. Additional policies SHOULD be registered with IANA as specified in Section 10.1.
为了在操作环境中实现一致的行为，应为环境记录优先级分配策略（以及对每个优先级的最大消息大小的可能相关限制（如果有）、默认超时等）。每个SMTP/LMTP服务器都支持优先级分配策略，无论是显式（在MT-Priority EHLO响应中公布）还是隐式（未公布）。附录B中规定了默认优先权分配政策（当MT-Priority EHLO响应中未公布优先权分配政策名称时，由客户承担）。附录A和附录C中规定了其他两项政策。应按照第10.1节的规定向IANA注册其他政策。
Moreover, all MSAs/MTAs/MDAs within any given Administrative Management Domain has to be configured to use the same Priority Assignment Policy. Otherwise, a differently configured MSA/MTA/MDA can expose the whole domain to possible attacks, like injection of a high-priority fake DSN.
此外，任何给定管理域中的所有MSA/MTA/MDA都必须配置为使用相同的优先级分配策略。否则，不同配置的MSA/MTA/MDA会使整个域暴露于可能的攻击之下，例如注入高优先级伪DSN。
When this SMTP extension is deployed across multiple cooperating Administrative Domains, such Administrative Domains need to use the same or at least compatible policies. Again, differences in policies (for example, differences in how users are authenticated or differences in how priorities are handled) can expose an Administrative Domain to weaknesses in a partner domain.
当跨多个协作管理域部署此SMTP扩展时，此类管理域需要使用相同或至少兼容的策略。同样，策略的差异（例如，用户身份验证方式的差异或优先级处理方式的差异）可能会使管理域暴露于合作伙伴域中的弱点。
IANA has added the MT-PRIORITY SMTP extension to the "SMTP Service Extensions" registry (http://www.iana.org/assignments/mail-parameters). This extension is suitable for the Submit port.
IANA已将MT优先级SMTP扩展添加到“SMTP服务扩展”注册表中(http://www.iana.org/assignments/mail-parameters). 此扩展适用于提交端口。
IANA has added the following new Received header field clause to the "Additional-registered-clauses" sub-registry (http://www.iana.org/assignments/mail-parameters) to help with tracing email messages delivered using the MT-PRIORITY SMTP extension:
IANA在“附加注册条款”子注册表中添加了以下新收到的标题字段条款(http://www.iana.org/assignments/mail-parameters)要帮助跟踪使用MT-PRIORITY SMTP扩展传递的电子邮件，请执行以下操作：
Clause name: PRIORITY Description: Records the value of the MT-PRIORITY parameter specified in the MAIL FROM command Syntax of the value: See Section 7 of RFC 6710 Reference: RFC 6710
子句名称：优先级描述：记录在MAIL FROM命令语法中指定的MT-PRIORITY参数的值：参见RFC 6710参考：RFC 6710第7节
IANA has added the following Enumerated Status Codes to the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes" registry (http://www.iana.org/assignments/smtp-enhanced-status-codes) established by [RFC5248]:
IANA已将下列枚举状态代码添加到“简单邮件传输协议（SMTP）增强状态代码”注册表中(http://www.iana.org/assignments/smtp-enhanced-status-codes)由[RFC5248]建立：
1) Code: X.7.15
1) 代码：X.7.15
Sample Text: Priority Level is too low
示例文本：优先级太低
Associated basic status code: 450, 550 (other 4XX or 5XX codes are allowed)
相关基本状态代码：450550（允许使用其他4XX或5XX代码）
Description: The specified priority level is below the lowest priority acceptable for the receiving SMTP server. This condition might be temporary, for example the server is operating in a mode where only higher-priority messages are accepted for transfer and delivery, while lower-priority messages are rejected.
说明：指定的优先级低于接收SMTP服务器可接受的最低优先级。这种情况可能是暂时的，例如，服务器运行的模式仅接受较高优先级的消息进行传输和传递，而拒绝较低优先级的消息。
Reference: RFC 6710
参考：RFC6710
Submitter: A. Melnikov
提交人：A.梅尔尼科夫
Change controller: IESG
更改控制器：IESG
2) Code: X.7.16
2) 代码：X.7.16
Sample Text: Message is too big for the specified priority
示例文本：对于指定的优先级，消息太大
Associated basic status code: 552 (other 4XX or 5XX codes are allowed)
关联的基本状态代码：552（允许使用其他4XX或5XX代码）
Description: The message is too big for the specified priority. This condition might be temporary, for example the server is operating in a mode where only higher-priority messages below a certain size are accepted for transfer and delivery.
描述：对于指定的优先级，消息太大。这种情况可能是暂时的，例如，服务器在一种模式下运行，在这种模式下，只有低于特定大小的高优先级邮件才能被接受进行传输和传递。
Reference: RFC 6710
参考：RFC6710
Submitter: A. Melnikov
提交人：A.梅尔尼科夫
Change controller: IESG
更改控制器：IESG
3) Code: X.3.6
3) 代码：X.3.6
Sample Text: Requested priority was changed
示例文本：请求的优先级已更改
Associated basic status code: 250 or 251
关联的基本状态代码：250或251
Description: The message was accepted for relay/delivery, but the requested priority (possibly the implied default) was not honored. The human readable text after the status code contains the new priority, followed by SP (space) and explanatory human readable text.
描述：已接受该消息进行中继/传递，但未遵守请求的优先级（可能是隐含的默认值）。状态代码后的人类可读文本包含新的优先级，后跟SP（空格）和解释性人类可读文本。
Reference: RFC 6710
参考：RFC6710
Submitter: A. Melnikov
提交人：A.梅尔尼科夫
Change controller: IESG
更改控制器：IESG
IANA has created a new IANA registry called "SMTP PRIORITY Extension Priority Assignment Policy". Future registrations in this registry are governed by the "Specification Required" [RFC5226] IANA registration policy. Requirements on registrations (to be verified by the Designated Expert) are specified in Section 10.1. Changes to registrations undergo the same process as initial registrations. In cases of significant changes to registrations (other than editorial clarifications), the Designated Expert MAY require registration of a Priority Assignment Policy with a new name instead of updating the existing one.
IANA已创建一个名为“SMTP优先级扩展优先级分配策略”的新IANA注册表。此注册表中的未来注册受“所需规范”[RFC5226]IANA注册策略的管辖。第10.1节规定了注册要求（由指定专家验证）。更改注册与初始注册经历相同的过程。如果注册发生重大变化（编辑澄清除外），指定专家可要求使用新名称注册优先权分配政策，而不是更新现有名称。
Priority Assignment Policy registrations with IANA are accompanied by a policy specification document that MUST specify the following information:
向IANA注册的优先权分配政策随附政策规范文件，该文件必须指定以下信息：
1. The Priority Assignment Policy name, which is a case-insensitive string of 1 to 20 US-ASCII characters to be advertised as the MT-PRIORITY EHLO parameter. Allowed characters are: ALPHA, DIGIT, "-", "_", and "."
1. 优先级分配策略名称，它是一个不区分大小写的字符串，由1到20个US-ASCII字符组成，将作为MT-Priority EHLO参数公布。允许使用的字符有：字母、数字、“-”、“x”和“.”
2. Number of distinct priority levels supported by all servers implementing the policy and their respective values.
2. 实现策略的所有服务器支持的不同优先级的数量及其各自的值。
3. For each supported priority level: default retry timeouts (how often to retry sending a message if there is a temporary error to transfer/deliver it). The policy specification can also explicitly define such information as implementation and/or deployment specific.
3. 对于每个支持的优先级：默认重试超时（如果传输/传递消息时出现临时错误，则重试发送消息的频率）。策略规范还可以明确定义实现和/或特定于部署的信息。
4. For each supported priority level: default expiration timeouts (how long to attempt transfer/delivery before the message expires and causes a non-delivery report to be generated). The policy specification can also explicitly define such information as implementation and/or deployment specific. Note that a client can override such default when it uses additional SMTP extensions (such as the one mentioned in Section 5.2).
4. 对于每个支持的优先级：默认过期超时（在邮件过期并导致生成未送达报告之前尝试传输/送达的时间）。策略规范还可以明确定义实现和/或特定于部署的信息。请注意，当客户端使用其他SMTP扩展（如第5.2节中提到的扩展）时，它可以覆盖此类默认值。
5. Maximum message size associated with each priority level. The policy specification can also explicitly define such information as implementation and/or deployment specific.
5. 与每个优先级关联的最大消息大小。策略规范还可以明确定义实现和/或特定于部署的信息。
6. Any requirements/restrictions on the kind of SMTP client authentication required in order for an SMTP server implementing this policy to accept priority values specified by an SMTP client. For example, this can limit which Simple Authentication and Security Layer (SASL) [RFC4422] authentication mechanisms are to be used, require TLS, etc.
6. 实现此策略的SMTP服务器接受SMTP客户端指定的优先级值所需的SMTP客户端身份验证类型的任何要求/限制。例如，这可以限制要使用的简单身份验证和安全层（SASL）[RFC4422]身份验证机制、需要TLS等。
7. Any other information that might affect processing of messages with different priorities.
7. 可能影响具有不同优先级的消息处理的任何其他信息。
8. Note that the policy specification document is not allowed to redefine the allowed range of priorities specified in Section 5 and other aspects of handling of different priorities, unless explicitly specified by this document.
8. 请注意，除非本文件明确规定，否则政策规范文件不允许重新定义第5节中规定的允许优先级范围以及处理不同优先级的其他方面。
IANA has registered the following initial values in the "SMTP PRIORITY Extension Priority Assignment Policy" registry:
IANA已在“SMTP优先级扩展优先级分配策略”注册表中注册了以下初始值：
Initial Priority Assignment Policy Registrations
初始优先级分配策略注册
+-------------+------------------------+----------------+
| Policy Name | Reference | Comment |
+-------------+------------------------+----------------+
| MIXER | Appendix B of RFC 6710 | Default policy |
| STANAG4406 | Appendix A of RFC 6710 | |
| NSEP | Appendix C of RFC 6710 | |
+-------------+------------------------+----------------+
+-------------+------------------------+----------------+
| Policy Name | Reference | Comment |
+-------------+------------------------+----------------+
| MIXER | Appendix B of RFC 6710 | Default policy |
| STANAG4406 | Appendix A of RFC 6710 | |
| NSEP | Appendix C of RFC 6710 | |
+-------------+------------------------+----------------+
Message Submission Agents ought to only accept message transfer priorities from users (or only certain groups of such users) who are authenticated and authorized in some way that's acceptable to the MSA. As part of this policy, they can also restrict maximum priority
消息提交代理应该只接受来自以MSA可接受的方式进行身份验证和授权的用户（或此类用户的某些组）的消息传输优先级。作为此策略的一部分，它们还可以限制最大优先级
values that different groups of users can request, and can override the priority values specified by MUAs.
不同用户组可以请求的值，并且可以覆盖MUA指定的优先级值。
Similarly, MTAs ought to only accept message transfer priorities from senders (or only certain groups of such senders) who are authenticated and authorized in some way that's acceptable to the MTA. As part of this policy, they can also restrict maximum priority values that different groups of senders can request, and can override the priority values specified by them.
类似地，MTA应该只接受发件人（或此类发件人的某些组）的邮件传输优先级，这些发件人通过某种MTA可以接受的方式进行身份验证和授权。作为此策略的一部分，它们还可以限制不同发件人组可以请求的最大优先级值，并可以覆盖它们指定的优先级值。
In the absence of the policy enforcement mentioned above, an SMTP server (whether an MSA or an MTA) implementing this SMTP extension might be susceptible to a denial-of-service attack. For example, malicious clients (MUAs/MSAs/MTAs) can try to abuse this feature by always requesting priority 9.
在没有上述策略实施的情况下，实现此SMTP扩展的SMTP服务器（无论是MSA还是MTA）可能会受到拒绝服务攻击。例如，恶意客户端（MUA/MSAs/MTA）可以尝试通过始终请求优先级9来滥用此功能。
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[RFC2033]迈尔斯，J.，“本地邮件传输协议”，RFC20331996年10月。
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC2034]Freed，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 20341996年10月。
[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月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.
[RFC5248]Hansen，T.和J.Klensin，“SMTP增强邮件系统状态代码的注册表”，BCP 138，RFC 5248，2008年6月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
[RFC6409]Gellens，R.和J.Klensin，“邮件信息提交”，STD 72，RFC 6409，2011年11月。
[ACP123] CCEB, "Common Messaging strategy and procedures", ACP 123, May 2009.
[ACP123]CCEB，“通用消息策略和程序”，ACP 123，2009年5月。
[PRIORITY-TUNNELING] Melnikov, A. and K. Carlberg, "Tunneling of SMTP Message Transfer Priorities", Work in Progress, July 2012.
[PRIORITY-TUNNELING]Melnikov，A.和K.Carlberg，“SMTP邮件传输优先级的隧道”，正在进行的工作，2012年7月。
[RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995.
[RFC1845]Crocker，D.，Freed，N.，和A.Cargille，“检查点/重启的SMTP服务扩展”，RFC 18451995年9月。
[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月。
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[RFC2156]Kille，S.，“混音器（Mime互联网X.400增强中继）：X.400和RFC 822/Mime之间的映射”，RFC 2156，1998年1月。
[RFC2205] Braden, B., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[RFC2852]Newman，D.，“通过SMTP服务扩展交付”，RFC 2852000年6月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC3207，2002年2月。
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
[RFC4125]Le Faucheur，F.和W.Lai，“区分服务感知MPLS流量工程的最大分配带宽约束模型”，RFC 41252005年6月。
[RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[RFC4127]Le Faucheur，F.，Ed.“区分服务感知MPLS流量工程的俄罗斯玩偶带宽约束模型”，RFC 4127，2005年6月。
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005.
[RFC4190]Carlberg，K.，Brown，I.，和C.Beard，“IP电话中支持紧急电信服务（ETS）的框架”，RFC 41902005年11月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412]Schulzrinne，H.和J.Polk，“会话启动协议（SIP）的通信资源优先级”，RFC 4412，2006年2月。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228]Guenther，P.，Ed.和T.Showalter，Ed.，“筛选：电子邮件过滤语言”，RFC 5228，2008年1月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC5598，2009年7月。
[RFC6401] Le Faucheur, F., Polk, J., and K. Carlberg, "RSVP Extensions for Admission Priority", RFC 6401, October 2011.
[RFC6401]Le Faucheur，F.，Polk，J.，和K.Carlberg，“入学优先权的RSVP延期”，RFC 6401，2011年10月。
[RFC6647] Kucherawy, M. and D. Crocker, "Email Greylisting: An Applicability Statement for SMTP", RFC 6647, June 2012.
[RFC6647]Kucherawy，M.和D.Crocker，“电子邮件灰色列表：SMTP的适用性声明”，RFC 6647，2012年6月。
[SMTP-PRI-OLD] Schmeing, M., Brendecke, J., and K. Carlberg, "SMTP Service Extension for Priority Message Handling", Work in Progress, August 2006.
[SMTP-PRI-OLD]Schmeing，M.，Brendecke，J.，和K.Carlberg，“优先邮件处理的SMTP服务扩展”，正在进行的工作，2006年8月。
[STANAG-4406] NATO, "STANAG 4406 Edition 2: Military Message Handling System", STANAG 4406, March 2005.
[STANAG-4406]北约，“STANAG 4406第2版：军事信息处理系统”，STANAG 4406，2005年3月。
Military Messaging as specified in ACP 123 [ACP123] (also specified in STANAG 4406 [STANAG-4406]) defines 6 priority ("precedence") values. While ACP 123/STANAG 4406 allow for 32 different priority levels (16 levels are reserved for NATO and an additional 16 are reserved for national use), only 6 are in use in practice. This section specifies the Priority Assignment Policy for Military Messaging and how the MT-PRIORITY parameter can be mapped when gatewaying between SMTP and ACP 123/STANAG 4406 environments.
ACP 123[ACP123]中规定的军事消息（也在STANAG 4406[STANAG-4406]中规定）定义了6个优先级（“优先级”）值。虽然ACP 123/STANAG 4406允许32种不同的优先级别（16个级别保留给北约，另外16个级别保留给国家使用），但实际上只有6个级别在使用。本节指定军事消息的优先级分配策略，以及在SMTP和ACP 123/STANAG 4406环境之间进行网关连接时，如何映射MT-Priority参数。
Where SMTP is used to support military messaging, the following mappings SHOULD be used.
如果SMTP用于支持军事消息传递，则应使用以下映射。
Recommended Mapping of MT-PRIORITY Values for MMHS
MMHS的MT优先级值的推荐映射
+-------------------+----------------------+
| MT-PRIORITY value | MMHS Precedence name |
+-------------------+----------------------+
| -4 | Deferred |
| -2 | Routine |
| 0 | Priority |
| 2 | Immediate |
| 4 | Flash |
| 6 | Override |
+-------------------+----------------------+
+-------------------+----------------------+
| MT-PRIORITY value | MMHS Precedence name |
+-------------------+----------------------+
| -4 | Deferred |
| -2 | Routine |
| 0 | Priority |
| 2 | Immediate |
| 4 | Flash |
| 6 | Override |
+-------------------+----------------------+
Table 1
表1
The Priority Assignment Policy registration for Military Messaging is as follows:
军事消息的优先级分配策略注册如下：
1. The Priority Assignment Policy name is "STANAG4406".
1. 优先级分配策略名称为“STANAG4406”。
2. Number of distinct priority levels: 6, as specified in the table above.
2. 不同优先级的数量：6，如上表所示。
3. Default retry timeouts for each priority level are implementation and/or deployment specific.
3. 每个优先级的默认重试超时是特定于实现和/或部署的。
4. Default expiration timeouts for each priority level are implementation and/or deployment specific.
4. 每个优先级的默认过期超时是特定于实现和/或部署的。
5. Maximum message size associated with each priority level is implementation and/or deployment specific.
5. 与每个优先级关联的最大消息大小取决于实现和/或部署。
6. No restrictions on what kind of SMTP client authentication is required.
6. 对需要何种SMTP客户端身份验证没有限制。
MIXER [RFC2156] defines the Priority header field with 3 values. This section specifies the Priority Assignment Policy for MIXER and how the MT-PRIORITY parameter can be mapped when used with MIXER.
混合器[RFC2156]用3个值定义优先级标头字段。本节指定混合器的优先级分配策略，以及与混合器一起使用时如何映射MT-Priority参数。
Where SMTP is used to support MIXER messaging, the following mappings SHOULD be used.
如果SMTP用于支持混合器消息传递，则应使用以下映射。
Recommended Mapping of MT-PRIORITY Values for MIXER
混合器MT优先级值的推荐映射
+-------------------+----------------------+
| MT-PRIORITY value | MIXER Priority value |
+-------------------+----------------------+
| -4 | non-urgent |
| 0 | normal |
| 4 | urgent |
+-------------------+----------------------+
+-------------------+----------------------+
| MT-PRIORITY value | MIXER Priority value |
+-------------------+----------------------+
| -4 | non-urgent |
| 0 | normal |
| 4 | urgent |
+-------------------+----------------------+
Table 2
表2
The Priority Assignment Policy registration for MIXER is as follows:
混音器的优先级分配策略注册如下：
1. The Priority Assignment Policy name is "MIXER".
1. 优先级分配策略名称为“混合器”。
2. Number of distinct priority levels: 3, as specified in the table above.
2. 不同优先级的数量：3，如上表所示。
3. Default retry timeouts for each priority level are implementation and/or deployment specific.
3. 每个优先级的默认重试超时是特定于实现和/或部署的。
4. Default expiration timeouts for each priority level are implementation and/or deployment specific.
4. 每个优先级的默认过期超时是特定于实现和/或部署的。
5. Maximum message size associated with each priority level is implementation and/or deployment specific.
5. 与每个优先级关联的最大消息大小取决于实现和/或部署。
6. No restrictions on what kind of SMTP client authentication is required.
6. 对需要何种SMTP客户端身份验证没有限制。
Appendix C. Priority Assignment Policy for National Security / Emergency Preparedness (NS/EP)
附录C.国家安全/应急准备优先分配政策（NS/EP）
There are several forms of communication systems used during an emergency or disaster. The most well known form involves the many-to-one model of the general public contacting a public safety access point via 911/999/112 calls through the public telephone network.
在紧急情况或灾难期间使用的通信系统有几种形式。最广为人知的形式包括多对一模式，即公众通过公共电话网络通过911/999/112电话联系公共安全接入点。
Typically, these calls do not require authorization, nor do they invoke any prioritization.
通常，这些调用不需要授权，也不调用任何优先级。
Another form of emergency communications involves a set of authorized users or nodes that use prioritized services to help establish and continue communication given limited available resources. [RFC4190] includes descriptions of several systems that have been developed to support National Security / Emergency Preparedness (NS/EP). These deployed systems require a form of authentication and have focused on prioritization of telephony-based services. They have also been designed as a binary form (on/off) of signaled priority communications.
另一种形式的紧急通信涉及一组授权用户或节点，在有限的可用资源下，这些用户或节点使用优先服务帮助建立和继续通信。[RFC4190]包括为支持国家安全/应急准备（NS/EP）而开发的几个系统的说明。这些部署的系统需要某种形式的身份验证，并将重点放在基于电话的服务的优先级上。它们还被设计为信号优先通信的二进制形式（开/关）。
[RFC4412] includes examples of a more expansive view of NS/EP communications in which priority migrates from a single on/off bit value to one that comprises 5 priority values. This is shown in the cases of the Emergency Telecommunications Service (ETS) and Wireless Priority Service (WPS) Namespaces. Given a lack of pre-existing NS/EP values assigned for email, we follow the paradigm of the ETS and WPS Namespaces and recommend the 5 ascending values shown in the table below.
[RFC4412]包括NS/EP通信更广泛视图的示例，其中优先级从单个开/关位值迁移到包含5个优先级值的值。这在紧急电信服务（ETS）和无线优先服务（WPS）名称空间的示例中显示。由于缺少为电子邮件分配的预先存在的NS/EP值，我们遵循ETS和WPS名称空间的范例，建议使用下表所示的5个升序值。
+-------------------+------------------+
| MT-PRIORITY value | Relational Order |
+-------------------+------------------+
| -2 | Lowest Priority |
| 0 | ---------- |
| 2 | ---------- |
| 4 | ---------- |
| 6 | Highest Priority |
+-------------------+------------------+
+-------------------+------------------+
| MT-PRIORITY value | Relational Order |
+-------------------+------------------+
| -2 | Lowest Priority |
| 0 | ---------- |
| 2 | ---------- |
| 4 | ---------- |
| 6 | Highest Priority |
+-------------------+------------------+
The Priority Assignment Policy registration for NS/EP is as follows:
NS/EP的优先级分配策略注册如下：
1. The Priority Assignment Policy name is "NSEP".
1. 优先级分配策略名称为“NSEP”。
2. Number of distinct priority levels: 5, as specified in the table above.
2. 不同优先级的数量：5，如上表所示。
3. Default retry timeouts for each priority level are implementation and/or deployment specific.
3. 每个优先级的默认重试超时是特定于实现和/或部署的。
4. Default expiration timeouts for each priority level are implementation and/or deployment specific.
4. 每个优先级的默认过期超时是特定于实现和/或部署的。
5. Maximum message size associated with each priority level is implementation and/or deployment specific.
5. 与每个优先级关联的最大消息大小取决于实现和/或部署。
6. No restrictions on what kind of SMTP client authentication is required.
6. 对需要何种SMTP客户端身份验证没有限制。
This appendix suggests some strategies to implement the SMTP extension defined in this document. The list is not exhaustive.
本附录提出了一些实现本文档中定义的SMTP扩展的策略。这份清单并非详尽无遗。
This appendix and its subsections are Informative.
本附录及其各小节为资料性附录。
As the name suggests, probability involves increasing the chances of obtaining resources without adversely affecting previously established connections. One example would involve requesting resources set aside for specific priority levels. If these additional resources are exhausted, then the desired connection is denied. Queues, new timers, or combinations thereof can be used to facilitate the higher-priority requests, but the key is that mechanisms focus on increasing the probability of message transfer.
顾名思义，概率包括在不影响先前建立的连接的情况下增加获得资源的机会。一个例子是要求为特定的优先级别预留资源。如果这些额外资源耗尽，则所需的连接将被拒绝。队列、新计时器或其组合可用于促进更高优先级的请求，但关键是机制侧重于提高消息传输的概率。
Preemption is a type of action that focuses only on a comparison of priorities to determine if previously established transactions need to be displaced in favor of higher-priority requests. If no additional connection is possible, the client aborts a running session for emails with lower priority no later than directly after the current transaction. The client can even interrupt an active transaction, and ought to do so if other constraints, such as delivery time (as specified in the DELIVERBY SMTP extension [RFC2852]), would be violated for the email with higher priority.
抢占是一种仅关注优先级比较的操作，以确定是否需要替换先前建立的事务以支持更高优先级的请求。如果没有额外的连接，客户端将在当前事务之后立即中止优先级较低的电子邮件的运行会话。客户机甚至可以中断活动事务，如果其他约束条件，如传递时间（如在DELIVERBY SMTP扩展[RFC2852]中指定的）将被违反，则应中断具有较高优先级的电子邮件。
When interrupting an active transaction, the client ought to take the total message size and the size of the transferred portion of the message being interrupted into consideration. This preliminary termination of sessions or transactions is called preemption.
当中断活动事务时，客户端应该考虑消息的总大小和被中断消息的传输部分的大小。会话或事务的这种初步终止称为抢占。
If preemption of running transactions occurs, the client needs to choose a transaction with the lowest priority currently processed.
如果发生对正在运行的事务的抢占，客户端需要选择当前处理的优先级最低的事务。
If the client has an option (i.e., it is supported by the next-hop MTA) to interrupt transactions in a way that allows them to be restarted at the interruption point later, it ought to deploy it. An example for a mechanism providing such a service is the "SMTP Service Extension for Checkpoint/Restart" defined in [RFC1845].
如果客户端有一个选项（即，下一跳MTA支持该选项）以允许事务稍后在中断点重新启动的方式中断事务，则应该部署它。提供此类服务的机制的一个示例是[RFC1845]中定义的“检查点/重启SMTP服务扩展”。
If a client opts for the preemption of sessions instead of transactions, it needs to preempt the next session that reaches the end of a transaction.
如果客户机选择抢占会话而不是事务，则需要抢占到达事务末尾的下一个会话。
Adding prioritization to a design moves the subject away from a strictly best effort (and a first-come-first-served) model to one that includes admission control and resource allocation models. Over the years, a variety of work has been done within the IETF to specify resource allocations models. Examples include the Maximum Allocation Model [RFC4125], the Russian Dolls Model [RFC4127], and the Priority Bypass Model (Appendix A.3 of [RFC6401]).
向设计添加优先级将主题从严格的尽力而为（以及先到先得）模型转移到包括准入控制和资源分配模型的模型。多年来，IETF中已经完成了各种工作，以指定资源分配模型。示例包括最大分配模型[RFC4125]、俄罗斯玩偶模型[RFC4127]和优先旁路模型（RFC6401的附录A.3]）。
While we recognize that these various models have been designed for other protocols (i.e., MPLS and RSVP), an understanding of their design characteristics may be beneficial in considering future implementations of a priority SMTP service.
虽然我们认识到这些不同的模型是为其他协议（即MPLS和RSVP）设计的，但了解它们的设计特征可能有助于考虑优先SMTP服务的未来实现。
In cases where the processing of high-priority messages by an MTA is not considered negligible and exceeds engineered expectations, then operators managing that MTA may be notified in some form (e.g., pushed alarm, polled status).
如果MTA对高优先级邮件的处理被认为是不可忽略的，并且超出了工程预期，则管理该MTA的操作员可能会收到某种形式的通知（例如，推送报警、轮询状态）。
This section provides some background on design choices made during development of the MT-PRIORITY SMTP extension.
本节提供了在开发MT-PRIORITY SMTP扩展期间所做设计选择的一些背景信息。
The priority applies per message, rather than per recipient, in order to keep the protocol simpler and because of the expectation that it will be uncommon to need different priorities for different recipients on the same message. In cases where that is necessary, it can always be achieved by sending separate messages with the same content, segregating the recipients by desired message priority.
优先级适用于每封邮件，而不是每封收件人，以使协议更简单，因为预期在同一封邮件上不同的收件人不需要不同的优先级。在必要的情况下，始终可以通过发送具有相同内容的单独邮件，按所需邮件优先级将收件人隔离来实现。
The choice of the priority range -9 to 9 (as opposed to, say, 1 to 6, or 0 to 9) was made after taking the following into consideration:
优先权范围-9至9（与1至6或0至9相反）的选择是在考虑以下因素后作出的：
1. Clearly, having multiple priority levels is the whole point of this extension. Existing implementations of similar functionality in MTAs are already using 3 levels. One of the use cases motivating this extension requires 6 levels, so at least 6 different values are required.
1. 显然，拥有多个优先级是这一扩展的重点。MTA中类似功能的现有实现已使用3个级别。推动此扩展的一个用例需要6个级别，因此至少需要6个不同的值。
2. During discussions of this extension, several different use cases were suggested that required differing numbers of priority levels. Defining just the 6 priority levels needed in item 1, above, would limit the extensibility for possible future use cases. Therefore, this document is defining a wider range, which allows implementations and deployments to add higher or lower priority levels and to insert additional priority levels between the recommended set of 6. This avoids the need to further extend this extension just to have a few more priority levels.
2. 在讨论这个扩展时，提出了几个不同的用例，它们需要不同数量的优先级。仅定义上述第1项中所需的6个优先级将限制未来可能用例的可扩展性。因此，本文档定义了更广泛的范围，允许实施和部署添加更高或更低的优先级，并在推荐的6组优先级之间插入其他优先级。这样就避免了为了获得更多的优先级而需要进一步扩展此扩展。
3. It seems natural to use zero for the "normal" or default priority, rather than picking some non-zero number and having the priorities go up or down from there. This way, negative numbers always represent priorities that are lower than normal, with positive numbers as higher priorities.
3. 对于“正常”或默认优先级，使用零似乎是很自然的，而不是选择一些非零的数字，然后让优先级从那里上升或下降。这样一来，负数总是代表比正常值低的优先级，而正数则代表更高的优先级。
This document copies lots of text from "SMTP Service Extension for Priority Message Handling" [SMTP-PRI-OLD]. Therefore, the authors of this document would like to acknowledge contributions made by the authors of that document: Michael Schmeing and Jan-Wilhelm Brendecke.
本文档从“优先邮件处理SMTP服务扩展”[SMTP-PRI-OLD]复制大量文本。因此，本文件的作者要感谢该文件的作者：Michael Schmeing和Jan Wilhelm Brendeck所作的贡献。
Many thanks for input provided by Steve Kille, David Wilson, John Klensin, Dave Crocker, Graeme Lunt, Alessandro Vesely, Barry Leiba, Bill McQuillan, Murray Kucherawy, SM, Glenn Parsons, Pete Resnick, Chris Newman, Ned Freed, and Claudio Allocchio.
非常感谢Steve Kille、David Wilson、John Klensin、Dave Crocker、Graeme Lunt、Alessandro Vesely、Barry Leiba、Bill McQuillan、Murray Kucherawy、SM、Glenn Parsons、Pete Resnick、Chris Newman、Ned Freed和Claudio Allocchio提供的意见。
Special thanks to Barry Leiba for agreeing to shepherd this document.
特别感谢Barry Leiba同意本文件。
Authors' Addresses
作者地址
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode有限公司TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Ken Carlberg G11 1601 Clarendon Blvd, #203 Arlington, VA 22209 USA
Ken Carlberg G11 1601美国弗吉尼亚州阿灵顿市克莱伦登大道203号，邮编22209
EMail: carlberg@g11.org.uk
EMail: carlberg@g11.org.uk