[要約] RFC 6710は、メッセージの送信優先度を設定するためのSMTP拡張機能についての規格です。このRFCの目的は、メールの送信優先度を制御するための標準化と、メールシステムの効率と信頼性の向上です。
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（Simple Mail Transfer Protocol）サービスの拡張を定義します。これにより、メッセージに優先処理を示すラベルが付けられ、メール処理ノードがこの情報を以降の処理で考慮できるようになります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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].
この拡張機能をサポートしていないメールインフラストラクチャ全体でエンドツーエンドで使用できるようにするために、新しいメッセージヘッダーフィールド[RFC5322]を使用するコンパニオントンネリングメカニズムが[PRIORITY-TUNNELING]で定義されています。
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）キューが構築されている場合にも役立ちます。上記の2つの条件のいずれにも当てはまらない場合、MT-PRIORITY SMTP拡張機能を使用しても、どのユーザーにとってもSMTPサービスが向上することにはなりません。また、このSMTP拡張機能は、優先度の高いメッセージの配信速度を改善するのに役立ちますが、優先度がMとN（M> N）の2つのメッセージが同時に送信され、優先度が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.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、それらがすべて大文字で現れる場合、[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].
正式な構文は、RFC 5234 [RFC5234]の付録Bで定義されているコアルールを含むAugmented Backus-Naur Form（ABNF）[RFC5234]表記を使用します。
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を参照）の名前を伝えるOPTIONALパラメーターがあります。 （その構文の詳細については、セクション7の<mt-priority-ehlo> ABNF非ターミナルを参照してください。）パラメーターがない場合、サーバーは優先順位割り当てポリシーを開示することを望まないことを意味します。クライアントは、サーバーによってアドバタイズされた特定の優先順位割り当てポリシー名を認識しない場合でも、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 described by the <priority-value> ABNF non-terminal defined in Section 7. Higher numbers mean higher priority.
5. MAIL FROMコマンドにオプションのパラメーター（「MT-PRIORITY」）が1つ追加されます。このパラメーターに関連付けられている値は、電子メールメッセージの優先度を示す-9〜9の10進整数です（この範囲が選択された理由の詳細については、付録Eを参照してください）。 MT-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. MAIL FROMコマンドラインの最大長は、スペース、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-PRIORITY拡張は、送信サービス[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-value>のいずれか（[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で指定されているようにReceivedヘッダーフィールドを挿入する場合、準拠するMTA / MSA（メール送信エージェント）には、セクション7で構文が指定されている「PRIORITY」句を含める必要があります（SHOULD）。
3. The received MT-PRIORITY parameter value SHOULD be logged as part of any logging of message transactions.
3. 受信したMT-PRIORITYパラメータ値は、メッセージトランザクションのロギングの一部として記録する必要があります（SHOULD）。
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クライアントがMT-PRIORITYパラメーターをMAIL FROMコマンドに指定した場合、このパラメーターの値はメッセージの優先度です。
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 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.
SMTPサーバーは、信頼できない（たとえば、認証されていない）ソースまたは許可されていないソースからの「アップグレードされた」（正の）優先順位を許可してはなりません（MUST NOT）。 （「許可されていないソース」の1つの例は、SMTP AUTHを使用して正常に認証されたが、SMTP MT-PRIORITYサービスの使用を明示的に許可されていないSMTP送信者である可能性があります。MTAからMTAへの転送の場合、このような許可は通常、 2つのドメイン間の双方向の合意として行われ、相互の優先順位を尊重します。ただし、サーバーは、信頼できないソースが自身のメッセージの優先順位を下げることを許可する場合があります。たとえば、マーケティングメッセージを自発的に送信するメールマーケティング担当者を検討してください負の優先順位。
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サーバーは、他のいくつかのサイトポリシーを実施するために、メッセージの優先度を（それを下げるまたは上げるために）変更することもできます（MAY）。 （これには、優先順位が明示的に指定されていない場合も含まれることに注意してください。）たとえば、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サーバーがメッセージの優先度を変更（下げるまたは上げる）する場合、MAIL FROMへの応答またはDATA（または同様の）コマンドへの最終応答でX.3.6拡張ステータスコード[RFC2034]を使用する必要があります（SHOULD）。ステータスコードの後の人間が読めるテキスト部分には、新しい優先度が含まれ、その後に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サーバーは、決定された優先順位に基づいてメッセージを拒否してもよい（MAY）。そのような場合、MSAは450または550応答コードを使用する必要があります（SHOULD）。決定された優先度レベルが、受信側の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:
次のルールは、SMTP / LMTPクライアントを介して受信したメッセージを、MT-PRIORITY拡張をサポートするSMTP / LMTPサーバーにリレーするときの、（SMTP / LMTPクライアントの役割における）適合MTAの動作を管理します。
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コマンドに、セクション4.1の手順で決定された値を持つMT-PRIORITYパラメータを指定する必要があります。 （サイトのポリシーにより、この値はSMTPクライアントから受信した値と異なる場合があります。詳細については、セクション4.1を参照してください。また、この値は、MTAが実際に要求を処理する優先度レベルと異なる場合があることに注意してください。セクション5で説明した丸めに。）
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:
次のルールは、SMTPプロトコルを介して受信したメッセージを、MT-PRIORITY拡張をサポートしないSMTP / LMTPサーバーにリレーするときの（SMTP / LMTPクライアントの役割における）適合MTAの動作を管理します。
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パラメーター値を保持する必要があります（SHOULD）。
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:
次のルールは、SMTPプロトコルを介して受信されたメッセージを外部（非SMTP）環境にゲートウェイ処理するときの適合MTAの動作を管理します。
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（配信の成功または配信の遅延/失敗）は、生成された配信レポートの優先度としてメッセージの優先度値を使用する必要があります（SHOULD）。特に、この要件は、[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の範囲の10進整数です。この仕様に準拠する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で決定された優先度の値を伝達しなければなりません（MUST）。
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 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].
優先度割り当てポリシーに従って、一部のSMTPサーバーは、異なるメッセージ転送優先度に対して追加の最大メッセージサイズの制約を課す場合があります。たとえば、優先度6のメッセージは4 KBを超えることはできません。決定された優先順位に対して大きすぎるためにSMTPサーバーがメッセージを拒否することを選択した場合、X.7.16拡張ステータスコード[RFC2034]とともに552応答コードを使用する必要があります（SHOULD）。
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 SIZE拡張[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.
Priorityサービス拡張は、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 AUTH、TLS、IPアドレスホワイトリストなどを使用するかどうか）が必要なため、このSMTP拡張機能を使用する送信者は対象になりません明示的なポリシー決定または設定ミスのエラーによりこのSMTP拡張機能の使用が許可されていない限り、グレイリスト[RFC6647]に。ただし、接続レベルまたはSMTP EHLO / HELOグレーリストの場合、SMTP AUTHまたは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サービス拡張による配信」（DELIVERBY拡張）は、タイムリーな配信の実装に使用できるサービスを提供するSMTP拡張機能の例です。 SMTP DELIVERBYおよびSMTP MT-PRIORITY拡張は補完的であり、一緒に使用できることに注意してください（両者が話しているSMTPサーバーが両方のサポートをアドバタイズしていると想定）。ただし、DELIVERBY拡張機能のみを使用しても、優先処理は保証されないことに注意してください。クライアントがSMTP DELIVERBYとSMTP MT-PRIORITYの両方を同時に使用している場合、クライアントは優先度の高いメッセージに対して、より小さいDELIVERBYタイムアウトを使用することを検討できます。
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サーバーは、MT-PRIORITY拡張が以前のSMTPホップで使用されたことをログに記録します。
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-PRIORITY拡張機能に関する情報をSieve [RFC5228]などの配信時間フィルタリングエンジンに公開しています。
priority-value = (["-"] NZDIGIT) / "0"
; Allowed values are from -9 to 9 inclusive
NZDIGIT = %x31-39
; "1"-"9"
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.
mt-priority-ehlo = "MT-PRIORITY" [SP priority-profile] ; Complies with the <ehlo-line> ABNF production ; from RFC 5321.
mt-priority-ehlo = "MT-PRIORITY" [SP優先度プロファイル]; <ehlo-line> ABNFプロダクションに準拠。 RFC 5321から。
priority-profile = 1*20(ALPHA / DIGIT / "-" / "_" / ".")
; name of the Priority Assignment Profile advertized in
; the MT-PRIORITY EHLO response.
ALPHA = <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へ）は、次のように表示されます。 MT-PRIORITY SMTP拡張機能が実装されている場合、これらの他の拡張機能がサポートされている必要はありませんが、この例ではSTARTTLS [RFC3207]、DELIVERBY [RFC2852]、DSN [RFC3461]の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
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を指定し、サーバーはそれを受け入れました。サーバーはMIXER優先順位割り当てポリシー（デフォルト）を通知しています。最初の提出の別のバリエーションは次のようになります。
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
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サーバーは、付録Aで説明されている6つの優先度レベルをサポートする「STANAG4406」優先度割り当てポリシーのサポートをアドバタイズします。これは、サーバーが優先度値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.
[RFC5321]のセクション5で、ドメインに複数のサーバーを指定するために複数のDNS MXレコードを使用する場合、それらすべてがMT-PRIORITY拡張をサポートし、優先度をまったく同じ方法で処理することを強くお勧めします。この点で1つ以上のサーバーの動作が異なる場合は、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応答でアドバタイズされる）または暗黙的（アドバタイズされない）であっても、優先順位割り当てポリシーをサポートします。デフォルトの優先順位割り当てポリシー（MT-PRIORITY EHLO応答で優先順位割り当てポリシー名が通知されない場合にクライアントが想定）は付録Bで指定されています。他の2つのポリシーは付録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-PRIORITY SMTP拡張機能を「SMTP Service Extensions」レジストリ（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: 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
IANAは、次の新しいReceivedヘッダーフィールド句を "Additional-registered-clauses"サブレジストリ（http://www.iana.org/assignments/mail-parameters）に追加し、MTを使用して配信された電子メールメッセージの追跡を支援します。 PRIORITY SMTP拡張機能：句名：PRIORITY説明：MAIL FROMコマンドで指定されたMT-PRIORITYパラメータの値を記録します。値の構文：RFC 6710のセクション7を参照してください。リファレンス：RFC 6710
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は、[RFC5248]によって確立された "Simple Mail Transfer Protocol（SMTP）Enhanced Status Codes"レジストリ（http://www.iana.org/assignments/smtp-enhanced-status-codes）に次の列挙型ステータスコードを追加しました。
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)
関連する基本ステータスコード：450、550（他の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
リファレンス：RFC 6710
Submitter: A. Melnikov
提出者：A. Melnikov
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
リファレンス：RFC 6710
Submitter: A. Melnikov
提出者：A. Melnikov
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
リファレンス：RFC 6710
Submitter: A. Melnikov
提出者：A. Melnikov
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 PRIORITY Extension Priority Assignment Policy」と呼ばれる新しいIANAレジストリを作成しました。このレジストリの今後の登録は、「必要な仕様」[RFC5226] IANA登録ポリシーによって管理されます。登録に関する要件（指定専門家によって検証される）は、セクション10.1で指定されています。登録の変更は、最初の登録と同じプロセスを経ます。登録に大幅な変更があった場合（編集による明確化以外）、指定専門家は、既存のポリシーを更新する代わりに、新しい名前で優先度割り当てポリシーを登録する必要があります（MAY）。
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. 優先順位割り当てポリシー名。MT-PRIORITYEHLOパラメーターとしてアドバタイズされる、大文字と小文字を区別しない1〜20文字のUS-ASCII文字の文字列です。使用できる文字は、ALPHA、DIGIT、「-」、「_」、および「。」です。
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クライアント認証の種類に関する要件/制限。たとえば、これにより、使用するSimple Authentication and Security Layer（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 PRIORITY Extension Priority Assignment Policy」レジストリに次の初期値を登録しています。
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 | |
+-------------+------------------------+----------------+
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 values that different groups of users can request, and can override the priority values specified by MUAs.
メッセージ送信エージェントは、MSAが許容できる何らかの方法で認証および承認されたユーザー（またはそのようなユーザーの特定のグループのみ）からのメッセージ転送の優先順位のみを受け入れる必要があります。このポリシーの一部として、ユーザーのさまざまなグループが要求できる最大優先度の値を制限したり、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 / MSA / MTA）は、常に優先度9を要求することにより、この機能を悪用しようとする可能性があります。
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[RFC2033] Myers、J。、「Local Mail Transfer Protocol」、RFC 2033、1996年10月。
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC2034] Freed、N。、「拡張エラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年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。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status Notifications（DSNs）」、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、「RFCで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]クロッカー、D。、エド。および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、「A Registry for SMTP Enhanced Mail System Status Codes」、BCP 138、RFC 5248、2008年6月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
[RFC6409] Gellens、R。およびJ. Klensin、「Mail for Submission for Mail」、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 Service Extension for Checkpoint / Restart」、RFC 1845、1995年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。、「MIXER（Mime Internet X.400 Enhanced Relay）：Mapping between X.400 and 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、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、9月1997年
[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、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、RFC 2474、1998年12月。
[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[RFC2852]ニューマン、D。、「SMTPサービス拡張による配信」、RFC 2852、2000年6月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207] Hoffman、P。、「Secure SMTP over Transport Layer SecurityのSMTPサービス拡張」、RFC 3207、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、「Diffserv対応MPLSトラフィックエンジニアリングの最大割り当て帯域幅制約モデル」、RFC 4125、2005年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。、編、「Diffserv対応の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 TelephonyでEmergency Telecommunications Service（ETS）をサポートするためのフレームワーク」、RFC 4190、2005年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、「Communications Resource Priority for the Session Initiation Protocol（SIP）」、RFC 4412、2006年2月。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]メルニコフ、A。、エド。 K. Zeilenga編、「Simple Authentication and Security Layer（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編、「Sieve：An Email Filtering Language」、RFC 5228、2008年1月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598] Crocker、D。、「Internet Mail Architecture」、RFC 5598、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 Extensions for Admission Priority」、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、「Email Greylisting：An Applicability Statement for SMTP」、RFC 6647、June 2012。
[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] NATO、「STANAG 4406 Edition 2：Military Message Handling System」、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レベルはNATO用に予約され、追加の16は国内使用のために予約されています）、実際に使用されているのは6つだけです。このセクションでは、Military Messagingの優先順位割り当てポリシーと、SMTP環境とACP 123 / STANAG 4406環境の間のゲートウェイ処理時にMT-PRIORITYパラメータをマップする方法を指定します。
Where SMTP is used to support military messaging, the following mappings SHOULD be used.
SMTPを使用して軍事メッセージングをサポートする場合は、次のマッピングを使用する必要があります（SHOULD）。
Recommended Mapping of MT-PRIORITY Values for MMHS
MMHSのMT-PRIORITY値の推奨マッピング
+-------------------+----------------------+
| 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.
MIXER [RFC2156]は、3つの値を持つPriorityヘッダーフィールドを定義します。このセクションでは、MIXERの優先順位割り当てポリシーと、MIXERで使用した場合のMT-PRIORITYパラメーターのマッピング方法を指定します。
Where SMTP is used to support MIXER messaging, the following mappings SHOULD be used.
SMTPを使用してMIXERメッセージングをサポートする場合は、次のマッピングを使用する必要があります（SHOULD）。
Recommended Mapping of MT-PRIORITY Values for MIXER
ミキサーのMT-PRIORITY値の推奨マッピング
+-------------------+----------------------+
| 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:
MIXERの優先順位割り当てポリシーの登録は次のとおりです。
1. The Priority Assignment Policy name is "MIXER".
1. 優先度割り当てポリシーの名前は「MIXER」です。
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コールを介して公衆安全アクセスポイントに連絡する一般公衆の多対1モデルです。
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 |
+-------------------+------------------+
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.
名前が示すように、確率には、以前に確立された接続に悪影響を与えずにリソースを取得できる可能性が高くなります。 1つの例として、特定の優先度レベル用に確保されたリソースを要求することが含まれます。これらの追加リソースが使い果たされると、必要な接続が拒否されます。キュー、新しいタイマー、またはそれらの組み合わせを使用して、優先度の高い要求を容易にすることができますが、重要なのは、メカニズムがメッセージ転送の確率を高めることに焦点を当てていることです。
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つのレベルを使用しています。この拡張機能を動機付けるユースケースの1つは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 Brendeckeによる貢献に感謝します。
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
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
Ken Carlberg G11 1601 Clarendon Blvd, #203 Arlington, VA 22209 USA
けん かｒｌべｒｇ Ｇ１１ １６０１ Ｃぁれんどん Ｂｌｖｄ、 ＃２０３ あｒぃんｇとん、 ゔぁ ２２２０９ うさ
EMail: carlberg@g11.org.uk