[要約] RFC 6758は、SMTPメッセージ転送の優先順位のトンネリングに関する規格です。その目的は、異なるネットワーク間でSMTPメッセージの優先順位を維持するための方法を提供することです。
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6758 Isode Ltd
Category: Informational K. Carlberg
ISSN: 2070-1721 G11
October 2012
Tunneling of SMTP Message Transfer Priorities
SMTPメッセージ転送優先度のトンネリング
Abstract
概要
This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension.
このメモは、MT-PRIORITY SMTP拡張機能をサポートしないMTA（メッセージ転送エージェント）を介したSMTP（簡易メール転送プロトコル）メッセージ転送優先度の値のトンネリングのメカニズムを定義します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6758.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6758で入手できます。
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 ....................................................2
2. Conventions Used in This Document ...............................3
3. Handling of Messages Received via SMTP ..........................4
3.1. Handling of the MT-PRIORITY Parameter by the
Receiving SMTP Server ......................................4
3.2. Relay of Messages to Other Conforming SMTP/LMTP Servers ....4
3.3. Relay of Messages to Non-Conforming SMTP/LMTP Servers ......5
3.4. Mailing Lists and Aliases ..................................5
3.5. Gatewaying a Message into a Foreign Environment ............5
3.6. Interaction with the DSN SMTP Extension ....................5
4. Header Field: MT-Priority .......................................5
5. Example .........................................................6
6. IANA Considerations .............................................7
7. Security Considerations .........................................7
7.1. Modification of the MT-Priority Header Field and DKIM ......9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
Appendix A. Acknowledgements ......................................11
The SMTP Message Transfer Priorities extension [RFC6710] specifies a mechanism to allow messages to be given a label to indicate preferential handling, to enable mail handling nodes to take this into account for onward processing. However, as with all SMTP extensions, all SMTP Message Transfer Agents (MTAs) between the source and the destination must support the extension in order for it to be successfully used. This document describes an application-layer tunneling of message priority, to convey the priority of the messages through MTAs that do not support the Message Transfer Priorities extension. The tunneling is done by adding a new message header field to the Internet Message Format specified in [RFC5322].
SMTPメッセージ転送優先度拡張[RFC6710]は、優先処理を示すラベルをメッセージに付与できるメカニズムを指定し、メール処理ノードがこれを以降の処理で考慮できるようにします。ただし、すべてのSMTP拡張機能と同様に、ソースと宛先の間のすべてのSMTPメッセージ転送エージェント（MTA）は、拡張機能を正常に使用するためにサポートする必要があります。このドキュメントでは、メッセージ転送の優先度拡張をサポートしないMTAを通じてメッセージの優先度を伝えるための、メッセージ優先度のアプリケーション層トンネリングについて説明します。トンネリングは、[RFC5322]で指定されたインターネットメッセージ形式に新しいメッセージヘッダーフィールドを追加することによって行われます。
A number of other header fields are already in use, mostly in Message User Agents (MUAs), to convey meanings related to importance or priority of messages. Examples of such header fields are Importance [RFC2156], Priority [RFC2156], and X-Priority (undocumented). Considering sometimes subtle and sometimes significant differences in the meaning of these header fields and widely different syntax, this document defines a new header field.
メッセージの重要性や優先度に関連する意味を伝えるために、他の多くのヘッダーフィールドが既に使用されており、そのほとんどがメッセージユーザーエージェント（MUA）にあります。そのようなヘッダーフィールドの例は、重要度[RFC2156]、優先度[RFC2156]、およびX-優先度（文書化されていない）です。これらのヘッダーフィールドと大幅に異なる構文の意味の微妙な違いと時には重要な違いを考慮して、このドキュメントでは新しいヘッダーフィールドを定義します。
This document is motivated by 2 main deployment scenarios: (1) an MUA talking to a non-MT-PRIORITY-aware Message Submission Agent (MSA), and (2) the use of an unextended MUA to talk to an MT-PRIORITY-aware MSA. These 2 use cases are discussed in more detail below.
このドキュメントは、2つの主な展開シナリオによって動機付けられています。（1）MUAが非MT-PRIORITY対応のメッセージ送信エージェント（MSA）と通信すること、（2）非拡張MUAを使用してMT-PRIORITY-と通信することです。 MSAを認識しています。これら2つの使用例について、以下で詳しく説明します。
Use case (1) is about an MT-PRIORITY-capable MUA talking to a non-MT-PRIORITY-capable MSA [RFC6409], which in turn is talking to an MT-PRIORITY-capable MTA [RFC5321]. Both the MSA and MTA are within the same ADministrative Management Domain (ADMD) and are on a fast network; however, some recipients are accessible via the MTA that is talking over a slow link to the next MTA. Communications over that slow link can benefit from the use of the MT-PRIORITY SMTP extension.
ユースケース（1）は、MT-PRIORITY対応のMUAがMT-PRIORITY非対応のMSA [RFC6409]と通信し、MSAがMT-PRIORITY対応のMTA [RFC5321]と通信している場合です。 MSAとMTAの両方が同じ管理管理ドメイン（ADMD）内にあり、高速ネットワーク上にあります。ただし、一部の受信者は、次のMTAへの低速リンクを介して通信しているMTAを介してアクセスできます。その低速リンクを介した通信は、MT-PRIORITY SMTP拡張機能を使用することでメリットを得られます。
In use case (2), a widely deployed client (such as a desktop client) is talking to an MT-PRIORITY-capable MSA. The client might be extendable via a plug-in API provided by the client developers; however, existing APIs frequently allow easy manipulation of email header fields, while not allowing for addition of SMTP protocol features. In such a case, installing a plug-in on the client that can set the MT-Priority header field could provide easier and earlier deployment of the MT-PRIORITY SMTP extension in an organization without requiring changes to desktop clients.
ユースケース（2）では、広く展開されているクライアント（デスクトップクライアントなど）がMT-PRIORITY対応のMSAと通信しています。クライアントは、クライアント開発者が提供するプラグインAPIを介して拡張できる場合があります。ただし、既存のAPIでは、SMTPプロトコル機能を追加できない一方で、電子メールヘッダーフィールドを簡単に操作できることがよくあります。このような場合、MT-Priorityヘッダーフィールドを設定できるプラグインをクライアントにインストールすると、デスクトップクライアントに変更を加えることなく、組織にMT-PRIORITY SMTP拡張機能をより簡単かつ早期に導入できます。
We note that the above use cases are not exhaustive and that other use cases -- variations of the above -- may exist. The purpose of this document is not to consider every scenario, but rather examples that reinforce the need to consider a tunneling mechanism that can deal with SMTP-capable devices that do not support [RFC6710].
上記のユースケースは網羅的ではなく、他のユースケース（上記のバリエーション）が存在する可能性があることに注意してください。このドキュメントの目的は、すべてのシナリオを検討することではなく、[RFC6710]をサポートしないSMTP対応デバイスを処理できるトンネリングメカニズムを検討する必要性を強調する例です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 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 subsections of this section update the corresponding subsections of Section 4 of [RFC6710].
このセクションのサブセクションは、[RFC6710]のセクション4の対応するサブセクションを更新します。
This specification inserts the following between steps 4 and 5 in Section 4.1 of [RFC6710]:
この仕様では、[RFC6710]のセクション4.1のステップ4と5の間に以下を挿入します。
4a. If the sending SMTP client hasn't specified the MT-PRIORITY parameter to the MAIL FROM command, but the message has a single syntactically valid MT-Priority header field (see Section 4), then the value of this header field is the message priority.
4a。送信SMTPクライアントがMAIL FROMコマンドにMT-PRIORITYパラメーターを指定していないが、メッセージに構文的に有効なMT-Priorityヘッダーフィールドが1つある場合（セクション4を参照）、このヘッダーフィールドの値はメッセージの優先度です。 。
4b. In the absence of both the MT-PRIORITY MAIL FROM parameter and the MT-Priority header field, other message header fields, such as Priority [RFC2156] and X-Priority, MAY be used for determining the priority under this "Priority Message Handling" SMTP extension. Note, however, that the Importance [RFC2156] header field MUST NOT be used for determining the priority under this "Priority Message Handling" SMTP extension, as it has different semantics: the Importance header field is aimed at the user recipient and not at the nodes responsible for transferring the message.
4b。 MT-PRIORITY MAIL FROMパラメーターとMT-Priorityヘッダーフィールドの両方がない場合、Priority [RFC2156]やX-Priorityなどの他のメッセージヘッダーフィールドを使用して、この「優先メッセージ処理」の優先順位を決定できます。 SMTP拡張。ただし、重要度[RFC2156]ヘッダーフィールドは、この「優先度メッセージ処理」SMTP拡張機能の優先度を決定するために使用してはならないことに注意してください。これは、意味が異なるためです。重要度ヘッダーフィールドは、メッセージの転送を担当するノード。
This specification inserts the following between steps 1 and 2 in Section 4.2 of [RFC6710].
この仕様では、[RFC6710]のセクション4.2のステップ1と2の間に以下を挿入します。
1a. Note that rule 1 also applies to messages that didn't have any priority explicitly specified using the MT-PRIORITY MAIL FROM parameter or the MT-Priority header field.
1a。ルール1は、MT-PRIORITY MAIL FROMパラメーターまたはMT-Priorityヘッダーフィールドを使用して明示的に指定された優先度がないメッセージにも適用されることに注意してください。
This specification appends the following after step 1 in Section 4.3 of [RFC6710]:
この仕様では、[RFC6710]のセクション4.3のステップ1の後に以下を追加します。
2. The relaying MTA MUST first remove any and all existing MT-Priority header fields from the message. (Please see Section 7 for additional considerations related to removal of the MT-Priority header field.)
2. 中継MTAは、まず既存のMT-Priorityヘッダーフィールドをメッセージから削除する必要があります。 （MT-Priorityヘッダーフィールドの削除に関する追加の考慮事項については、セクション7を参照してください。）
3. If the incoming message had an MT-PRIORITY parameter specified in the MAIL FROM command *or* there was an MT-Priority header field removed in step 2 above, then the relaying MTA MUST add its own MT-Priority header field with the value determined by the procedure in Section 3.1. The syntax of the MT-Priority header field is specified in Section 4.
3. 着信メッセージのMAIL FROMコマンドでMT-PRIORITYパラメータが指定されている場合*または*上記の手順2でMT-Priorityヘッダーフィールドが削除されている場合、中継MTAは、決定された値で独自のMT-Priorityヘッダーフィールドを追加する必要がありますセクション3.1の手順による。 MT-Priorityヘッダーフィールドの構文は、セクション4で指定されています。
This specification makes no changes to Section 4.4 of [RFC6710].
この仕様は、[RFC6710]のセクション4.4を変更しません。
This specification inserts the following between steps 1 and 2 in Section 4.5 of [RFC6710].
この仕様では、[RFC6710]のセクション4.5のステップ1と2の間に以下を挿入します。
1a. Note that if the destination environment doesn't support the transport of an arbitrary header field, the requirement in Section 3.3 to add an MT-Priority header field doesn't apply.
1a。宛先環境が任意のヘッダーフィールドの転送をサポートしていない場合、セクション3.3のMT-Priorityヘッダーフィールドを追加する要件は適用されないことに注意してください。
This specification makes no changes to Section 4.6 of [RFC6710].
この仕様は、[RFC6710]のセクション4.6を変更しません。
Applicable protocol: mail [RFC5322]
Status: standard
Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org)
on behalf of the IETF
Specification document(s): RFC 6758
The MT-Priority header field conveys message transfer priority when relaying a message through MTAs that don't support the MT-PRIORITY SMTP extension.
MT-PRIORITY SMTP拡張をサポートしていないMTAを介してメッセージをリレーする場合、MT-Priorityヘッダーフィールドはメッセージ転送の優先度を伝えます。
The ABNF for this header field is defined as follows:
このヘッダーフィールドのABNFは次のように定義されます。
priority-header-field = "MT-Priority:" [CFWS] priority-value [CFWS] CRLF
priority-header-field = "MT-Priority：" [CFWS] priority-value [CFWS] CRLF
where "priority-value" is defined in [RFC6710].
「priority-value」は、[RFC6710]で定義されています。
Example: MT-Priority: -3
例：MT優先度：-3
Example: MT-Priority: 4 (ultra)
例：MT優先度：4（超）
Note that the following example of an SMTP transaction with 2 recipients is also making use of the STARTTLS [RFC3207] and Delivery Status Notification (DSN) [RFC3461] SMTP extensions, even though there is no requirement that these other extensions are to be supported when the MT-PRIORITY SMTP extension is implemented.
次の2つの受信者を持つSMTPトランザクションの例は、STARTTLS [RFC3207]および配信ステータス通知（DSN）[RFC3461] SMTP拡張機能も使用していることに注意してください。 MT-PRIORITY SMTP拡張機能が実装されています。
S: 220 example.net SMTP server here
C: EHLO example.com
S: 250-example.net
S: 250-DSN
S: 250-STARTTLS
S: 250 MT-PRIORITY STANAG4406
C: STARTTLS
[...TLS negotiation...]
C: MAIL FROM:<eljefe@example.com> 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
Here, the receiving SMTP server supports the "STANAG4406" Priority Assignment Policy [RFC6710] with 6 priority levels, so it 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). When relaying the message to the next hop that doesn't support the MT-PRIORITY SMTP extension, the transaction might look like this:
ここで、受信SMTPサーバーは6つの優先度レベルで「STANAG4406」優先度割り当てポリシー[RFC6710]をサポートしているため、内部で優先度値4（次にサポートされる優先度3以上）を使用し、次の場合に優先度値3を通知します。それを次のホップに中継します（必要な場合）。 MT-PRIORITY SMTP拡張機能をサポートしていない次のホップにメッセージをリレーする場合、トランザクションは次のようになります。
S: 220 example.org SMTP server here
C: EHLO example.net
S: 250-example.org
S: 250-DSN
S: 250-STARTTLS
S: 250 SIZE
C: STARTTLS
[...TLS negotiation...]
C: MAIL FROM:<eljefe@example.com> ENVID=QQ314159
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: MT-Priority: 3
C: (the rest of the message goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
IANA has added the following list of header field names to the "Permanent Message Header Field Names" registry (in <http://www.iana.org/assignments/message-headers/perm-headers.html>):
IANAは、ヘッダーフィールド名の次のリストを "Permanent Message Header Field Names"レジストリ（<http://www.iana.org/assignments/message-headers/perm-headers.html>内）に追加しました。
Header field: MT-Priority
Applicable protocol: mail
Status: standard
Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org)
on behalf of the IETF
Specification document(s): RFC 6758
This document allows a message priority to be tunneled through MTAs that don't support the MT-PRIORITY SMTP extension by specifying how it can be represented in the message itself (using the MT-Priority header field). Thus, it is important to ensure that an MTA receiving a message containing the MT-Priority header field can trust that it was set by an authorized agent. The use of technologies such as DomainKeys Identified Mail (DKIM) [RFC6376] or S/MIME to sign the MT-Priority header field value can enable a recipient to verify whether the specified priority value was generated by a trusted agent. In particular, DKIM signing allows a recipient to verify that the specified priority value was present when the message was signed, and to verify who signed the message. Note, however, that the DKIM signer might not be the same agent that generated the MT-Priority header field.
このドキュメントでは、MT-PRIORITY SMTP拡張をサポートしていないMTAを介してメッセージの優先度をトンネリングできるようにします（MT-Priorityヘッダーフィールドを使用して）メッセージ自体でメッセージの優先度を表現する方法を指定します。したがって、MT-Priorityヘッダーフィールドを含むメッセージを受信するMTAが、許可されたエージェントによって設定されたことを信頼できることを確認することが重要です。 DomainKeys Identified Mail（DKIM）[RFC6376]やS / MIMEなどのテクノロジーを使用してMT-Priorityヘッダーフィールド値に署名すると、受信者は、指定された優先度値が信頼できるエージェントによって生成されたかどうかを確認できます。特に、DKIM署名を使用すると、受信者は、メッセージの署名時に指定された優先度の値が存在していたことを確認し、誰がメッセージに署名したかを確認できます。ただし、DKIM署名者は、MT-Priorityヘッダーフィールドを生成したエージェントとは異なる場合があることに注意してください。
MSAs ought to only accept message transfer priorities (whether by using the MT-PRIORITY parameter to the MAIL FROM command or the MT-Priority header field in the message itself) 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. When relaying to non-MT-PRIORITY-capable SMTP/LMTP (Local Mail Transfer Protocol) servers, such MSAs are required to replace any MT-Priority header field values that don't satisfy this policy. See Section 7.1 for more details on what the consequences of such changes might be.
MSAは、認証および承認されたユーザー（またはそのようなユーザーの特定のグループのみ）からのメッセージ転送の優先順位（MAIL FROMコマンドのMT-PRIORITYパラメーターを使用するか、メッセージ自体のMT-Priorityヘッダーフィールドを使用するか）のみを受け入れる必要がありますある意味では、それはMSAに受け入れられます。このポリシーの一部として、さまざまなユーザーグループが要求できる最大優先度の値を制限したり、MUAで指定された優先度の値を上書きしたりすることもできます。 MT-PRIORITY非対応のSMTP / LMTP（ローカルメール転送プロトコル）サーバーに中継する場合、このようなMSAは、このポリシーを満たさないMT-Priorityヘッダーフィールド値を置き換える必要があります。そのような変更の影響についての詳細は、セクション7.1を参照してください。
Similarly, MTAs ought to only accept message transfer priorities (whether by using the MT-PRIORITY parameter to the MAIL FROM command or the MT-Priority header field in the message itself) 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. When relaying to non-MT-PRIORITY-capable SMTP/ LMTP servers, such MTAs are required to replace any MT-Priority header field values that don't satisfy this policy. See Section 7.1 for more details on what the consequences of such changes might be.
同様に、MTAは、認証された送信者（またはそのような送信者の特定のグループのみ）からのメッセージ転送の優先順位（MAIL FROMコマンドへのMT-PRIORITYパラメータまたはメッセージ自体のMT-Priorityヘッダーフィールドの使用による）のみを受け入れる必要があります。 MTAに受け入れられる何らかの方法で承認されます。このポリシーの一部として、送信者の異なるグループが要求できる最大優先度値を制限したり、それらによって指定された優先度値を上書きしたりすることもできます。 MT-PRIORITY非対応のSMTP / LMTPサーバーにリレーする場合、このようなMTAは、このポリシーを満たさないMT-Priorityヘッダーフィールド値を置き換える必要があります。そのような変更の影響についての詳細は、セクション7.1を参照してください。
In the absence of the policy enforcement mentioned above, an SMTP server (whether an MSA or an MTA) implementing the MT-PRIORITY 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.
上記のポリシーが適用されていない場合、MT-PRIORITY SMTP拡張機能を実装しているSMTPサーバー（MSAまたはMTA）は、サービス拒否攻撃を受けやすい可能性があります。たとえば、悪意のあるクライアント（MUA / MSA / MTA）は、常に優先度9を要求することにより、この機能を悪用しようとする可能性があります。
To protect the MT-Priority header field from modification or insertion, MUAs, MSAs, and MTAs inserting it into messages SHOULD use a message header protection mechanism such as DKIM [RFC6376]; however, see Section 7.1 for more information.
MT-Priorityヘッダーフィールドを変更または挿入から保護するには、MUA、MSA、およびメッセージに挿入するMTAがDKIM [RFC6376]などのメッセージヘッダー保護メカニズムを使用する必要があります。ただし、詳細についてはセクション7.1を参照してください。
An MSA/MTA that receives a message with an MT-Priority header field protected by DKIM and that wants to change the message priority due to its policy is forced to choose between
DKIMで保護されたMT-Priorityヘッダーフィールドを持つメッセージを受信し、そのポリシーのためにメッセージの優先度を変更する必要があるMSA / MTAは、どちらかを選択する必要があります
a. breaking DKIM signatures (by replacing the MT-Priority header value),
a. DKIM署名の破壊（MT-Priorityヘッダー値を置き換えることにより）、
b. leaving the message as is (and using the MT-PRIORITY MAIL FROM parameter), relying on the fact that all downstream MTAs are compliant with this specification, and
b. メッセージをそのまま残して（およびMT-PRIORITY MAIL FROMパラメーターを使用して）、すべてのダウンストリームMTAがこの仕様に準拠しているという事実に依存します。
c. rejecting the message.
c. メッセージを拒否します。
None of these choices are perfect. They work in a particular situation, so these choices should be carefully considered during implementation and deployment.
これらの選択肢はどれも完璧ではありません。これらは特定の状況で機能するため、これらの選択は、実装および展開時に慎重に検討する必要があります。
If the MSA/MTA decides to alter the message, it SHOULD re-sign the message with DKIM.
MSA / MTAがメッセージを変更することを決定した場合は、DKIMでメッセージに再署名する必要があります（SHOULD）。
[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月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[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月。
[RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer Protocol Extension for Message Transfer Priorities", RFC 6710, August 2012.
[RFC6710] Melnikov、A。およびK. Carlberg、「メッセージ転送優先度のためのシンプルなメール転送プロトコル拡張」、RFC 6710、2012年8月。
[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月。
[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月。
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376] Crocker、D.、Hansen、T。、およびM. Kucherawy、「DomainKeys Identified Mail（DKIM）Signatures」、RFC 6376、2011年9月。
[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月。
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, Claudio Allocchio, Martin Thomson, and Joseph Yee.
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