RFC 8494 - Multicast Email (MULE) over Allied Communications Publication (ACP) 142 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8494
タイトル : RFC 8494 - Allied Communications Publication（ACP）142上のマルチキャストメール（MULE）
翻訳編集 : 自動生成

[要約] RFC 8494は、Allied Communications Publication (ACP) 142上でのMulticast Email (MULE)の実装に関する要件を定義しています。このRFCの目的は、ACP 142を使用して効率的かつ信頼性の高いマルチキャストメールの配信を実現することです。

Independent Submission                                         D. Wilson
Request for Comments: 8494                              A. Melnikov, Ed.
Category: Informational                                        Isode Ltd
ISSN: 2070-1721                                            November 2018

Multicast Email (MULE) over Allied Communications Publication (ACP) 142

Allied Communications Publication（ACP）142上のマルチキャストメール（MULE）

Abstract

概要

Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (Multicast Email), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP 142). MULE enables transfer between Message Transfer Agents (MTAs). It doesn't provide a service similar to SMTP Submission (as described in RFC 6409).

Allied Communications Publication（ACP）142はP_MULを定義しています。P_MULは、UDPで実行される帯域幅が制限された遅延確認応答（Emissions Controlまたは "EMCON"）環境に適した信頼性の高いマルチキャストのプロトコルです。このドキュメントでは、MULE（マルチキャスト電子メール）を定義します。これは、P_MUL（ACP 142で定義）を介してインターネットメールメッセージ（RFC 5322で説明）を転送するためのアプリケーションプロトコルです。 MULEは、メッセージ転送エージェント（MTA）間の転送を可能にします。 SMTP送信（RFC 6409で説明されている）と同様のサービスは提供しません。

This document explains how MULE can be used in conjunction with SMTP (RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism.

このドキュメントでは、MULEをSMTP（RFC 5321）と組み合わせて、いくつかの一般的なSMTP拡張機能を含めて、代替のMTAからMTAへの転送メカニズムを提供する方法について説明します。

This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics.

これはIETF仕様ではありません。既存の実装について説明しています。相互運用可能な実装とサードパーティの診断を容易にするために提供されています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8494.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8494で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1. Introduction ....................................................3
   2. Conventions Used in This Document ...............................4
   3. MULE ............................................................4
      3.1. BSMTP-Like Payload Construction ............................6
      3.2. Payload Compression ........................................7
      3.3. Error Handling .............................................9
   4. Gatewaying from Internet Mail to MULE ...........................9
      4.1. Use of BDAT ...............................................10
   5. Gatewaying from MULE to Internet Mail ..........................10
      5.1. Handling of ESMTP Extensions and Errors ...................10
   6. IANA Considerations ............................................11
      6.1. Instructions for Designated Experts .......................11
      6.2. SMTP Extension Support in MULE ............................12
   7. Security Considerations ........................................14
   8. References .....................................................15
      8.1. Normative References ......................................15
      8.2. Informative References ....................................17
   Acknowledgements ..................................................19
   Authors' Addresses ................................................19

1. Introduction

1. はじめに

P_MUL [ACP142A] is a transport protocol for reliable multicast in bandwidth-constrained and delayed acknowledgement environments running on top of UDP. This document defines MULE, an application protocol for transferring Internet Mail messages [RFC5322] over ACP 142 P_MUL. The objectives of MULE are 1) to take advantage of the bandwidth-saving feature of using the multicast service as supported by modern computer networks and 2) to allow message transfer under EMCON (Emissions Control) conditions. EMCON or "radio silence" means that although receiving nodes are able to receive messages, they are not able to acknowledge the receipt of messages.

P_MUL [ACP142A]は、UDP上で実行される帯域幅が制限された遅延確認応答環境での信頼性の高いマルチキャストのためのトランスポートプロトコルです。このドキュメントは、MULEを定義します。これは、ACP 142 P_MULを介してインターネットメールメッセージ[RFC5322]を転送するためのアプリケーションプロトコルです。 MULEの目的は、1）最新のコンピューターネットワークでサポートされているマルチキャストサービスを使用することで帯域幅を節約する機能を利用すること、および2）EMCON（Emissions Control）条件下でのメッセージ転送を可能にすることです。 EMCONまたは「無線無音」とは、受信ノードはメッセージを受信できますが、メッセージの受信を確認できないことを意味します。

The objective of this protocol is to take advantage of multicast communication for the transfer of messages between MTAs (Message Transfer Agents) on a single multicast network under normal (i.e., dialog-oriented) communication conditions and under EMCON conditions. An "EMCON condition" means that a receiving node is able to receive messages but cannot acknowledge the received messages for a relatively long time (hours or even days).

このプロトコルの目的は、通常の（つまり、ダイアログ指向の）通信条件下およびEMCON条件下で、単一のマルチキャストネットワーク上のMTA（メッセージ転送エージェント）間でメッセージを転送するためにマルチキャスト通信を利用することです。「EMCON状態」とは、受信ノードがメッセージを受信できるが、比較的長い時間（数時間または場合によっては数日）の間、受信したメッセージを確認できないことを意味します。

Figure 1 illustrates a simple multicast scenario, where the same message has to be sent from MTA A (through G/W) to MTA 1, MTA 2, MTA 3, and MTA 4.

図1は、同じメッセージをMTA Aから（G / W経由で）MTA 1、MTA 2、MTA 3、およびMTA 4に送信する必要がある単純なマルチキャストシナリオを示しています。

                             +-------+                   +-------+
                             | MTA 1 |<-\             /->| MTA 3 |
    +-------+     +-----+    +-------+   \ +-------+ /   +-------+
    | MTA A |<--->| G/W |<---------------->| Router|<
    +-------+     +-----+    +-------+   / +-------+ \   +-------+
                             | MTA 2 |<-/             \->| MTA 4 |
                             +-------+                   +-------+

                           |< -------------- MULE ---------------->|

Note: The gateway (G/W) and Router might or might not be running on the same system.

注：ゲートウェイ（G / W）とルーターは、同じシステムで実行されている場合とされていない場合があります。

Figure 1: Typical MULE Deployment

図1：典型的なMULEデプロイメント

Due to multicast use (instead of a unicast communication service) in the above MTA configuration, only one message transmission from the gateway to the Router is required in order to reach MTA 1, MTA 2, MTA 3, and MTA 4, instead of four as required with unicast. This saves the transmission three message transactions and thus results in savings in bandwidth utilization. Depending on the network bandwidth (in some radio networks, it is less than 9.6 Kb/s), this savings can be of vital importance. The savings in bandwidth utilization become even greater with every additional receiving MTA.

上記のMTA構成では（ユニキャスト通信サービスの代わりに）マルチキャストを使用するため、ゲートウェイからルーターへのメッセージ送信は、MTA 1、MTA 2、MTA 3、およびMTA 4に到達するために4つではなく1つだけ必要です。ユニキャストで必要に応じて。これにより、3つのメッセージトランザクションの送信が節約され、帯域幅の使用率が節約されます。ネットワーク帯域幅（一部の無線ネットワークでは9.6 Kb / s未満）によっては、この節約が非常に重要になる場合があります。帯域幅使用率の節約は、MTAを受信するたびにさらに大きくなります。

P_MUL employs a connectionless transport protocol to transmit messages. This guarantees reliable message transfer (through ACP 142 retransmissions) even in cases where one or more of the receiving MTAs are not able or allowed to acknowledge completely received messages for a certain period of time.

P_MULは、コネクションレス型トランスポートプロトコルを使用してメッセージを送信します。これにより、1つ以上の受信MTAが一定期間完全に受信したメッセージを確認できない、または許可できない場合でも、（ACP 142再送信による）信頼性の高いメッセージ転送が保証されます。

This protocol specification requires fixed multicast groups and knowledge of the group memberships in one or more multicast groups of each participating node (MTA). Membership in multicast groups needs to be established before MULE messages can be sent.

このプロトコル仕様には、固定マルチキャストグループと、各参加ノード（MTA）の1つ以上のマルチキャストグループのグループメンバーシップに関する知識が必要です。 MULEメッセージを送信する前に、マルチキャストグループのメンバーシップを確立する必要があります。

MULE enables MTA-to-MTA transfer. It doesn't provide service similar to SMTP Submission [RFC6409].

MULEはMTAからMTAへの転送を可能にします。 SMTP Submission [RFC6409]のようなサービスは提供していません。

2. Conventions Used in This Document

2. このドキュメントで使用される規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

This document also uses terminology from [RFC5321] and [RFC5598].

このドキュメントでは、[RFC5321]および[RFC5598]の用語も使用しています。

3. MULE

3. ミュール

MULE is an electronic mail transport of Internet Mail messages [RFC5322] over an ACP 142 P_MUL network. It provides service similar to MTA-to-MTA SMTP [RFC5321]. This document doesn't define a service similar to SMTP Submission [RFC6409].

MULEは、ACP 142 P_MULネットワーク上のインターネットメールメッセージ[RFC5322]の電子メール転送です。 MTA-to-MTA SMTP [RFC5321]と同様のサービスを提供します。このドキュメントでは、SMTP Submission [RFC6409]と同様のサービスを定義していません。

An important feature of MULE is its capability to transport mail across multiple networks, referred to as "MULE mail relaying". A network consists of the nodes that are mutually accessible by ACP 142. Using MULE, a process can transfer mail to another process on the same ACP 142 network or to some other ACP 142 network via a relay or gateway process accessible to both networks.

MULEの重要な機能は、「MULEメールリレー」と呼ばれる、複数のネットワーク間でメールを転送する機能です。ネットワークは、ACP 142によって相互にアクセス可能なノードで構成されています。MULEを使用すると、プロセスは、同じACP 142ネットワーク上の別のプロセスまたは両方のネットワークにアクセス可能なリレーまたはゲートウェイプロセスを介して他のACP 142ネットワークにメールを転送できます。

MULE reuses the ESMTP extension framework defined in [RFC5321]. MULE servers MUST support the following ESMTP extensions: DSN [RFC3461], SIZE [RFC1870], 8BITMIME [RFC6152], MT-PRIORITY [RFC6710], DELIVERBY [RFC2852], BINARYMIME [RFC3030], and CHUNKING [RFC3030]. (As the message content size can always be determined from the compression wrapper and the size of the envelope, no special handling is needed for binary messages.)

MULEは、[RFC5321]で定義されているESMTP拡張フレームワークを再利用します。 MULEサーバーは次のESMTP拡張をサポートする必要があります：DSN [RFC3461]、SIZE [RFC1870]、8BITMIME [RFC6152]、MT-PRIORITY [RFC6710]、DELIVERBY [RFC2852]、BINARYMIME [RFC3030]、CHUNKING [RFC3030]。（メッセージのコンテンツサイズは常に圧縮ラッパーとエンベロープのサイズから決定できるため、バイナリメッセージの場合は特別な処理は必要ありません。）

Relaying a message using MULE is performed as follows:

MULEを使用したメッセージのリレーは、次のように実行されます。

1. The message is reassembled from one or more DATA_PDUs [ACP142A].

1. メッセージは、1つ以上のDATA_PDU [ACP142A]から再構成されます。

2. If the contentType-ShortForm value is 25, the BSMTP-like payload is extracted from the compressedContent field and uncompressed (the reverse of the compression process specified in Section 3.2). If the contentType-ShortForm value is not 25, it is handled as described in [ACP142A]. This document doesn't further discuss any cases where the contentType-ShortForm value is not 25.

2. contentType-ShortForm値が25の場合、BSMTPのようなペイロードは、compressedContentフィールドから抽出され、圧縮されません（セクション3.2で指定された圧縮プロセスの逆）。 contentType-ShortForm値が25でない場合、[ACP142A]で説明されているように処理されます。このドキュメントでは、contentType-ShortFormの値が25でない場合の詳細については説明しません。

3. The list of recipients is extracted from RCPT-lines (see Section 3.1). If the receiving node is not responsible (directly or indirectly) for any of the recipients, the message is discarded and no further processing is done.

3. 受信者のリストは、RCPT行から抽出されます（セクション3.1を参照）。受信ノードがいずれかの受信者に対して（直接的または間接的に）責任を負わない場合、メッセージは破棄され、それ以上の処理は行われません。

4. The relay adds trace header fields, e.g., the Received header field. See [RFC7601] and Section 4.4 of [RFC5321].

4. リレーは、Receivedヘッダーフィールドなどのトレースヘッダーフィールドを追加します。 [RFC7601]と[RFC5321]のセクション4.4をご覧ください。

5. The set of ACP 142 destinations for the message is created by extracting right-hand sides (hostnames) of each RCPT-line, eliminating duplicates, and then converting each hostname into the next ACP 142 destination using static configuration.

5. メッセージのACP 142宛先のセットは、各RCPT行の右側（ホスト名）を抽出し、重複を排除してから、静的構成を使用して各ホスト名を次のACP 142宛先に変換することによって作成されます。

6. For each unique ACP 142 destination, the following steps are performed:

6. 一意のACP 142宛先ごとに、次の手順が実行されます。

A. A new BSMTP-like payload is formed, as described in Section 3.1, that only contains RCPT-lines that correspond to recipients that can receive mail through the ACP 142 destination.

A. 3.1で説明したように、ACP 142宛先を介してメールを受信できる受信者に対応するRCPT行のみを含む、新しいBSMTPのようなペイロードが形成されます。

B. The created payload is compressed and encoded as specified in Section 3.2.

B.作成されたペイロードは、セクション3.2で指定されているとおりに圧縮およびエンコードされます。

C. The compressed payload is sent by P_MUL as a series of an Address_PDU and one or more DATA_PDUs. When the message has an associated MT-PRIORITY value [RFC6710], the MappedPriority(value) is included as the Priority field of the corresponding ACP 142 PDUs, including Address_PDUs, DATA_PDUs, and DISCARD_MESSAGE_PDUs. Here, MappedPriority(x) is defined as "6 - x".

C.圧縮されたペイロードは、一連のAddress_PDUおよび1つ以上のDATA_PDUとしてP_MULによって送信されます。メッセージに関連するMT-PRIORITY値[RFC6710]がある場合、MappedPriority（value）は、Address_PDU、DATA_PDU、およびDISCARD_MESSAGE_PDUを含む、対応するACP 142 PDUのPriorityフィールドとして含まれます。ここでは、MappedPriority（x）は「6-x」として定義されています。

3.1. BSMTP-Like Payload Construction

3.1. BSMTPのようなペイロード構築

MULE uses a BSMTP-like payload that differs from Batch SMTP (BSMTP) [RFC2442] in that it eliminates unnecessary information. As with BSMTP, ESMTP capability negotiation is not used, since receiver EMCON restrictions prohibit such real-time interaction. For that reason, there is no point in including EHLO capabilities. "MAIL FROM:" and "RCPT TO:" prefixes are also excluded in order to save a few bytes.

MULEは、Batch SMTP（BSMTP）[RFC2442]とは異なるBSMTPのようなペイロードを使用しており、不要な情報を排除します。 BSMTPと同様に、レシーバーEMCONの制限により、このようなリアルタイムの相互作用が禁止されるため、ESMTP機能ネゴシエーションは使用されません。そのため、EHLO機能を含めても意味がありません。数バイトを節約するために、「MAIL FROM：」および「RCPT TO：」プレフィックスも除外されます。

For each received message, the corresponding BSMTP-like payload is constructed as follows. Note that lines are terminated using CR LF.

受信したメッセージごとに、対応するBSMTPのようなペイロードが次のように構築されます。行はCR LFを使用して終了することに注意してください。

1. The first line is what would be used for the data following "MAIL FROM:" in the SMTP dialog, i.e., it contains the return-path address (including the angle brackets -- "<" and ">") followed by any ESMTP extension parameters to the MAIL FROM command.

1. 最初の行は、SMTPダイアログの "MAIL FROM："に続くデータに使用されるものです。つまり、リターンパスアドレス（山かっこ-"<"と ">"を含む）に続いてESMTPが含まれます。 MAIL FROMコマンドの拡張パラメーター。

2. After that, there is a separate line for each recipient of the message. The value is what would follow "RCPT TO:" in the SMTP dialog, i.e., the recipient address (including the angle brackets -- "<" and ">") followed by any ESMTP extension parameters to the corresponding RCPT TO command.

2. その後、メッセージの受信者ごとに個別の行があります。値は、SMTPダイアログの「RCPT TO：」の後に続くものです。つまり、対応するRCPT TOコマンドへのESMTP拡張パラメーターが後に続く受信者アドレス（山かっこ-「<」と「>」を含む）です。

3. The list of recipients is terminated by an empty line (i.e., just CR LF).

3. 受信者のリストは空行で終了します（つまり、CR LFのみ）。

4. The message content follows the empty line. There is no need for transparency ("dot stuffing") or terminating with a sequence "CR LF . CR LF", as the end of the message content is indicated by the end of the data (see Section 3.2 for more details).

4. メッセージの内容は空行の後に続きます。メッセージ内容の終わりはデータの終わりで示されるため（詳細についてはセクション3.2を参照）、透明性（「ドットスタッフィング」）やシーケンス「CR LF。CR LF」で終了する必要はありません。

The following is an example of a BSMTP-like payload:

以下は、BSMTPのようなペイロードの例です。

  <from@example.com> MT-PRIORITY=4 BODY=8BITMIME RET=HDRS ENVID=QQ314159
  <to1@example.net> NOTIFY=FAILURE ORCPT=rfc822;Bob@ent.example.net
  <to2@example.net> NOTIFY=SUCCESS,FAILURE

  From: from@example.com
  To: To1 <to1@example.net>, To2 <to2@example.net>
  Date: 27 Apr 2017 16:17 +0100
  Subject: a test
  MIME-Version: 1.0
  Content-type: text/plain; charset=utf-8
  Content-transfer-encoding: 8bit

This is worth <poundsign>100

これは<poundsign> 100の価値があります

ABNF [RFC5234] for the BSMTP-like payload is:

BSMTPのようなペイロードのABNF [RFC5234]は次のとおりです。

bsmtp-like-payload = envelope CRLF payload envelope = FROM-line 1*RCPT-line FROM-line = reverse-path [SP mail-parameters] CRLF RCPT-line = forward-path [SP rcpt-parameters] CRLF

bsmtp-like-payload =エンベロープCRLFペイロードエンベロープ= FROM-line 1 * RCPT-line FROM-line = reverse-path [SP mail-parameters] CRLF RCPT-line = forward-path [SP rcpt-parameters] CRLF

   payload = *OCTET
             ; Conforms to message syntax as defined in RFC 5322
             ; and extended in MIME

   OCTET = <any 0-255 octet value>
   reverse-path = <as defined in RFC 5321>
   forward-path = <as defined in RFC 5321>
   mail-parameters = <as defined in RFC 5321>
   rcpt-parameters = <as defined in RFC 5321>

3.2. Payload Compression

3.2. ペイロード圧縮

A BSMTP-like payload (Section 3.1) is first compressed using zlibCompress [RFC1950]. This compressed payload is placed in the compressedContent field of the CompressedContentInfo element defined in Section 4.2.6 of [STANAG-4406]. This is then encoded as BER encoding [ITU.X690.2002] of the CompressedData ASN.1 structure. For convenience, the original definition of the CompressedData ASN.1 structure is included below. The contentType-ShortForm value used by MULE MUST be 25. (The contentType-OID alternative is never used by MULE.)

BSMTPのようなペイロード（セクション3.1）は、最初にzlibCompress [RFC1950]を使用して圧縮されます。この圧縮されたペイロードは、[STANAG-4406]のセクション4.2.6で定義されたCompressedContentInfo要素の圧縮コンテンツフィールドに配置されます。これは、CompressedData ASN.1構造のBERエンコード[ITU.X690.2002]としてエンコードされます。便宜上、CompressedData ASN.1構造の元の定義を以下に示します。 MULEが使用するcontentType-ShortFormの値は25でなければなりません（MULEはcontentType-OIDの代替を決して使用しません）。

The above procedure is similar to how X.400 messages are sent using Annex E of [STANAG-4406]. This makes it easier to implement MTAs that support both Internet messages and X.400 messages in the same code base.

上記の手順は、[STANAG-4406]のAnnex Eを使用してX.400メッセージを送信する方法と似ています。これにより、同じコードベースでインターネットメッセージとX.400メッセージの両方をサポートするMTAを実装しやすくなります。

The Compressed Data Type (CDT) consists of content of any type that is compressed using a specified algorithm. The following object identifier identifies the CDT:

圧縮データタイプ（CDT）は、指定されたアルゴリズムを使用して圧縮された任意のタイプのコンテンツで構成されます。次のオブジェクト識別子はCDTを識別します。

   id-mmhs-CDT ID ::= { iso(1) identified-organization(3) nato(26)
                        stanags(0) mmhs(4406) object-identifiers(0)
                        id-mcont(4) 2 }

The CDT is defined by the following ASN.1 type. Note that this definition is copied from [STANAG-4406] and is only reproduced here for the reader's convenience.

CDTは、次のASN.1タイプによって定義されます。この定義は[STANAG-4406]からコピーされ、読者の便宜のためにここでのみ複製されていることに注意してください。

 DEFINITIONS ::=
 BEGIN
 CompressedData ::= SEQUENCE {
                    compressionAlgorithm CompressionAlgorithmIdentifier,
                    compressedContentInfo CompressedContentInfo
                    }
 CompressionAlgorithmIdentifier ::= CHOICE {
                      algorithmID-ShortForm [0] AlgorithmID-ShortForm,
                      algorithmID-OID [1] OBJECT IDENTIFIER
                    }
 AlgorithmID-ShortForm ::= INTEGER { zlibCompress (0) }
 CompressedContentInfo ::= SEQUENCE {
                      CHOICE {
                        contentType-ShortForm [0] ContentType-ShortForm,
                        contentType-OID [1] OBJECT IDENTIFIER
                      },
                      compressedContent [0] EXPLICIT OCTET STRING
                    }
 ContentType-ShortForm ::= INTEGER {
                      unidentified (0),
                      external (1), -- identified by the
                                    -- object-identifier
                                    -- of the EXTERNAL content
                      p1 (2),
                      p3 (3),
                      p7 (4)
                    }
 END

This document effectively adds another enumeration choice to the ContentType-ShortForm definition. The updated definition looks like this:

このドキュメントは、ContentType-ShortForm定義に別の列挙型の選択肢を効果的に追加します。更新された定義は次のようになります。

   ContentType-ShortForm ::= INTEGER {
                        unidentified (0),
                        external (1), -- identified by the
                                      -- object-identifier
                                      -- of the EXTERNAL content
                        p1 (2),
                        p3 (3),
                        p7 (4),
                        mule (25)
                      }

3.3. Error Handling

3.3. エラー処理

MULE doesn't allow a next-hop Message Transfer Agent / Mail Delivery Agent (MTA/MDA) to return immediate Response Codes for the FROM-line or any of the recipients in the RCPT-line. Therefore, when MTAs/MDAs that are compliant with this specification receive a message that can't be relayed further or delivered, they MUST generate a non-delivery DSN report [RFC6522] message that includes the message/ delivery-status body part [RFC3464] and submit it using MULE to the FROM-line return-path address.

MULEは、ネクストホップメッセージ転送エージェント/メール配信エージェント（MTA / MDA）が、FROM行またはRCPT行の受信者のいずれかの即時応答コードを返すことを許可しません。したがって、この仕様に準拠するMTA / MDAは、それ以上中継または配信できないメッセージを受信すると、メッセージ/配信ステータスのボディパーツ[RFC3464]を含む配信不能DSNレポート[RFC6522]メッセージを生成する必要があります。 ]そして、MULEを使用してFROM-line return-pathアドレスに送信します。

MULE relays (unlike MULE MDAs) don't need to verify that they understand all FROM-line and/or RCPT-line parameters. This keeps relay-only implementations simpler and avoids the need to upgrade them when MULE MDAs are updated to support extra SMTP extensions.

MULEリレー（MULE MDAとは異なります）は、FROM回線とRCPT回線のすべてのパラメーターを理解していることを確認する必要はありません。これにより、リレーのみの実装がよりシンプルになり、追加のSMTP拡張機能をサポートするようにMULE MDAが更新されたときに、それらをアップグレードする必要がなくなります。

4. Gatewaying from Internet Mail to MULE

4. インターネットメールからMULEへのゲートウェイ

A gateway from Internet Mail to MULE acts as an SMTP server on the receiving side and as a MULE client on the sending side.

インターネットメールからMULEへのゲートウェイは、受信側ではSMTPサーバーとして機能し、送信側ではMULEクライアントとして機能します。

When the content type for a message is an Internet message content type (which may be 7-bit, 8-bit, or binary MIME), this is transported using ACP 142 [ACP142A] as follows:

メッセージのコンテンツタイプがインターネットメッセージコンテンツタイプ（7ビット、8ビット、またはバイナリMIMEの場合があります）の場合、これは次のようにACP 142 [ACP142A]を使用して転送されます。

1. For each mail message, a BSMTP-like payload is formed, as described in Section 3.1.

1. セクション3.1で説明するように、各メールメッセージに対してBSMTPのようなペイロードが形成されます。

2. The created payload is compressed and encoded, as specified in Section 3.2.

2. 作成されたペイロードは、セクション3.2で指定されているように、圧縮およびエンコードされます。

3. The compressed payload is sent by P_MUL as a series of an Address_PDU and one or more DATA_PDUs. When the message has an associated MT-PRIORITY value [RFC6710], the MappedPriority(value) is included as the Priority field of the corresponding ACP 142 PDUs, including Address_PDUs, DATA_PDUs, and DISCARD_MESSAGE_PDUs. Here, MappedPriority(x) is defined as "6 - x".

3. 圧縮されたペイロードは、一連のAddress_PDUおよび1つ以上のDATA_PDUとしてP_MULによって送信されます。メッセージに関連するMT-PRIORITY値[RFC6710]がある場合、MappedPriority（value）は、Address_PDU、DATA_PDU、およびDISCARD_MESSAGE_PDUを含む、対応するACP 142 PDUのPriorityフィールドとして含まれます。ここでは、MappedPriority（x）は「6-x」として定義されています。

The set of ACP 142 destinations for the message is derived from the next-hop MTAs for each of the recipients.

メッセージのACP 142宛先のセットは、各受信者のネクストホップMTAから取得されます。

4.1. Use of BDAT

4.1. BDATの使用

If a message is received by a gateway through SMTP transfers using the CHUNKING [RFC3030] extension, the message is rebuilt by the receiving MTA into its complete form and is then used as a single MULE message payload. Use of the BINARYMIME [RFC3030] extension is conveyed by inclusion of the BODY=BINARY parameter in the FROM-line.

メッセージがCHUNKING [RFC3030]拡張を使用したSMTP転送を介してゲートウェイによって受信される場合、メッセージは受信MTAによって完全な形式に再構築され、単一のMULEメッセージペイロードとして使用されます。 BINARYMIME [RFC3030]拡張の使用は、FROM行にBODY = BINARYパラメータを含めることで伝えられます。

5. Gatewaying from MULE to Internet Mail

5. MULEからインターネットメールへのゲートウェイ

A gateway from MULE to Internet Mail acts as a MULE server on the receiving side and as an SMTP client on the sending side.

MULEからインターネットメールへのゲートウェイは、受信側ではMULEサーバーとして機能し、送信側ではSMTPクライアントとして機能します。

Gatewaying from an ACP 142 environment to Internet Email is the reverse of the process specified in Section 4.

ACP 142環境からインターネット電子メールへのゲートウェイは、セクション4で指定したプロセスの逆です。

1. The ACP 142 message is reassembled from one or more DATA_PDUs.

1. ACP 142メッセージは、1つ以上のDATA_PDUから再構成されます。

3. The BSMTP-like payload is converted to an SMTP transaction (see Section 3.1). (The first line of the BSMTP-like payload is prepended with "MAIL FROM:", and each following line (until the empty line is encountered) is prepended with "RCPT TO:". After skipping the empty delimiting line, the rest of the payload is the message body. This can be sent using either DATA or a series of BDAT commands, depending on the capabilities of the receiving SMTP system. For example, the presence of the BODY=BINARY parameter in the FROM-line would necessitate the use of BDAT or down-conversion of the message to 7-bit compatible representation.)

3. BSMTPのようなペイロードは、SMTPトランザクションに変換されます（セクション3.1を参照）。（BSMTPのようなペイロードの最初の行には "MAIL FROM："が先頭に追加され、後続の各行（空の行が検出されるまで）には "RCPT TO："が先頭に追加されます。空の区切り行をスキップすると、残りのペイロードはメッセージ本文です。これは、受信側のSMTPシステムの機能に応じて、DATAまたは一連のBDATコマンドを使用して送信できます。たとえば、FROM行にBODY = BINARYパラメータがあると、 BDATの使用またはメッセージの7ビット互換表現へのダウンコンバージョン。）

5.1. Handling of ESMTP Extensions and Errors

5.1. ESMTP拡張機能とエラーの処理

ESMTP extension parameters to MAIL FROM and RCPT TO SMTP commands obtained from a BSMTP-like payload are processed according to specifications of the corresponding ESMTP extensions. This includes dealing with the absence of support for ESMTP extensions that correspond to MAIL FROM and RCPT TO parameters found in the BSMTP-like payload.

BSMTPのようなペイロードから取得したMAIL FROMおよびRCPT TO SMTPコマンドへのESMTP拡張パラメーターは、対応するESMTP拡張の仕様に従って処理されます。これには、BSMTPのようなペイロードにあるMAIL FROMおよびRCPT TOパラメータに対応するESMTP拡張機能のサポートの欠如への対処が含まれます。

Failures to extract or uncompress BSMTP-like payloads should result in the receiver discarding such payloads.

BSMTPのようなペイロードの抽出または圧縮解除に失敗すると、受信者はそのようなペイロードを破棄する必要があります。

6. IANA Considerations

6. IANAに関する考慮事項

IANA has created a new "Multicast Email SMTP Extensions" registry under the "MAIL Parameters" registry. The registration procedure for this new registry is "Specification Required" [RFC8126]. The designated expert(s) will be appointed and managed by the editors of this document together with the Independent Submissions Editor. Selected designated expert(s) should (collectively) have a good knowledge of SMTP (and its extensions and extensibility mechanisms), as well as ACP 142 and its limitations. The subsections below provide more details: Section 6.1 specifies instructions for the designated expert(s), and Section 6.2 defines the initial content of the registry.

IANAは、「MAIL Parameters」レジストリの下に新しい「Multicast Email SMTP Extensions」レジストリを作成しました。この新しいレジストリの登録手順は、「指定が必要」[RFC8126]です。指定されたエキスパートは、独立した投稿の編集者とともにこのドキュメントの編集者によって任命され、管理されます。選択された専門家は、SMTP（およびその拡張機能と拡張性メカニズム）、およびACP 142とその制限について（集合的に）十分な知識を持っている必要があります。以下のサブセクションで詳細を説明します。セクション6.1は指定されたエキスパートへの指示を指定し、セクション6.2はレジストリの初期コンテンツを定義します。

6.1. Instructions for Designated Experts

6.1. 指定専門家向けの手順

The designated expert(s) for the new "Multicast Email SMTP Extensions" registry verifies that:

新しい「Multicast Email SMTP Extensions」レジストリに指定されたエキスパートは、次のことを確認します。

1. The requested SMTP extension is already registered in the "SMTP Service Extensions" registry under the "MAIL Parameters" registry on the IANA website or is well documented on a stable, publicly accessible web page.

1. 要求されたSMTP拡張機能は、IANA Webサイトの[MAIL Parameters]レジストリの下にある[SMTP Service Extensions]レジストリにすでに登録されているか、安定した公開されたWebページに文書化されています。

2. The requested SMTP extension has the correct status as specified in Section 6.2. When deciding on status, the designated expert(s) is provided with the following guidelines:

2. 要求されたSMTP拡張機能は、セクション6.2で指定されている正しいステータスになっています。ステータスを決定する場合、指定されたエキスパートには次のガイドラインが提供されます。

A. If the SMTP extension only affects commands other than MAIL FROM and RCPT TO, then the status should be "N/A".

A. SMTP拡張機能がMAIL FROMおよびRCPT TO以外のコマンドにのみ影響する場合、ステータスは「N / A」になります。

B. If the SMTP extension only applies to SMTP Submission [RFC6409] (and not to SMTP relay or final SMTP delivery), then the status should be "N/A".

B. SMTP拡張機能がSMTP送信[RFC6409]にのみ適用され、SMTPリレーや最終的なSMTP配信には適用されない場合、ステータスは「N / A」になります。

C. If the SMTP extension changes which commands are allowed during an SMTP transaction (e.g., if it adds commands alternative to DATA or declares commands other than MAIL FROM, RCPT TO, DATA, and BDAT to be a part of SMTP transaction), then the status should be "Disallowed" or "Special".

C. SMTP拡張機能がSMTPトランザクション中に許可されるコマンドを変更する場合（たとえば、DATAの代わりにコマンドを追加するか、MAIL FROM、RCPT TO、DATA、およびBDAT以外のコマンドをSMTPトランザクションの一部として宣言する場合）、次にステータスは「Disallowed」または「Special」である必要があります。

D. If the SMTP extension adds extra round trips during SMTP transaction, then the status should be "Disallowed" or "Special".

D. SMTP拡張がSMTPトランザクション中に余分なラウンドトリップを追加する場合、ステータスは "Disallowed"または "Special"になります。

Registration requests should include the SMTP extension name, status (see Section 6.2), and specification reference. They may also include an optional note.

登録要求には、SMTP拡張名、ステータス（セクション6.2を参照）、および仕様リファレンスを含める必要があります。オプションのメモが含まれる場合もあります。

6.2. SMTP Extension Support in MULE

6.2. MULEでのSMTP拡張機能のサポート

The following table summarizes how different SMTP extensions can be used with MULE. Each extension has one of the following statuses:

次の表は、MULEでさまざまなSMTP拡張機能をどのように使用できるかをまとめたものです。各拡張機能には、次のいずれかのステータスがあります。

o Required - support by MULE relays, SMTP-to-MULE gateway, or MULE-to-SMTP gateway is required.

o 必須-MULEリレー、SMTPからMULEへのゲートウェイ、またはMULEからSMTPへのゲートウェイによるサポートが必要です。

o Disallowed - incompatible with MULE.

o 許可されていません-MULEと互換性がありません。

o N/A - not relevant because the extension affects commands other than MAIL FROM and/or RCPT TO or is only defined for SMTP Submission [RFC6409]. Such extensions can still be used on the receiving SMTP side of an SMTP-to-MULE gateway.

o N / A-拡張はMAIL FROMおよび/またはRCPT TO以外のコマンドに影響するか、SMTP送信[RFC6409]に対してのみ定義されているため、関連性はありません。そのような拡張機能は、SMTP-to-MULEゲートウェイの受信側のSMTP側でも引き続き使用できます。

o Supported - can be used with MULE but requires bilateral agreement between sender and receiver.

o サポート-MULEで使用できますが、送信者と受信者間の双方向の合意が必要です。

o Special - needs to be accompanied by an explanation.

o 特別-説明が必要です。

          +------------------------+---------------+-----------+
          | SMTP Extension Keyword | Status        | Reference |
          +------------------------+---------------+-----------+
          | SIZE                   | Required      | [RFC1870] |
          |                        |               |           |
          | 8BITMIME               | Required      | [RFC6152] |
          |                        |               |           |
          | DSN                    | Required      | [RFC3461] |
          |                        |               |           |
          | MT-PRIORITY            | Required      | [RFC6710] |
          |                        |               |           |
          | DELIVERBY              | Required      | [RFC2852] |
          |                        |               |           |
          | BINARYMIME             | Required      | [RFC3030] |
          |                        |               |           |
          | CHUNKING               | Special (*)   | [RFC3030] |
          |                        |               |           |
          | ENHANCEDSTATUSCODES    | Special (**)  | [RFC2034] |
          |                        |               |           |
          | RRVS                   | Supported     | [RFC7293] |
          |                        |               |           |
          | SUBMITTER              | Supported     | [RFC4405] |
          |                        |               |           |
          | PIPELINING             | N/A           | [RFC2920] |
          |                        |               |           |
          | STARTTLS               | N/A           | [RFC3207] |
          |                        |               |           |
          | AUTH                   | Special (***) | [RFC4954] |
          |                        |               |           |
          | BURL                   | N/A           | [RFC4468] |
          |                        |               |           |
          | NO-SOLICITING          | N/A           | [RFC3865] |
          |                        |               |           |
          | CHECKPOINT             | Disallowed    | [RFC1845] |
          |                        |               |           |
          | CONNEG                 | Disallowed    | [RFC4141] |
          +------------------------+---------------+-----------+

Table 1: Initial Content of Multicast Email SMTP Extensions Registry

表1：マルチキャスト電子メールSMTP拡張機能レジストリの初期コンテンツ

(*) - SMTP CHUNKING MUST be supported on the receiving SMTP side of an SMTP-to-MULE gateway and MAY be used on the sending side of a MULE-to-SMTP gateway. A MULE relay doesn't need to do anything special for this extension.

（*）-SMTP CHUNKINGは、SMTPからMULEへのゲートウェイの受信SMTP側でサポートされている必要があり、MULEからSMTPへのゲートウェイの送信側で使用できます（MAY）。 MULEリレーは、この拡張のために特別なことをする必要はありません。

(**) - The ENHANCEDSTATUSCODES extension is supported by including relevant status codes in DSN [RFC3461] reports.

（**）-DSN [RFC3461]レポートに関連するステータスコードを含めることにより、ENHANCEDSTATUSCODES拡張がサポートされます。

   (***) - The AUTH parameter to the MAIL FROM command is "Supported",
   but the rest of the AUTH extension is not applicable to MULE.

Note that the above table is not exhaustive. Future RFCs can define how SMTP extensions not listed above can be used in MULE.

上記の表は完全なものではないことに注意してください。将来のRFCでは、上記にリストされていないSMTP拡張機能をMULEで使用する方法を定義できます。

7. Security Considerations

7. セキュリティに関する考慮事項

As MULE provides a service similar to SMTP, many of the security considerations from [RFC5321] apply to MULE as well; in particular, Sections 7.1, 7.2, 7.4, 7.6, 7.7, and 7.9 of [RFC5321] apply to MULE.

MULEはSMTPと同様のサービスを提供するため、[RFC5321]のセキュリティに関する考慮事項の多くがMULEにも適用されます。特に、[RFC5321]のセクション7.1、7.2、7.4、7.6、7.7、および7.9がMULEに適用されます。

As MULE doesn't support capability negotiation or the SMTP HELP command, Section 7.5 of [RFC5321] ("Information Disclosure in Announcements") doesn't apply to MULE.

MULEは機能ネゴシエーションまたはSMTP HELPコマンドをサポートしていないため、[RFC5321]のセクション7.5（「お知らせの情報開示」）はMULEには適用されません。

As MULE doesn't support the VRFY or EXPN SMTP commands, Section 7.3 of [RFC5321] ("VRFY, EXPN, and Security"), which discusses email harvesting, doesn't apply to MULE.

MULEはVRFYまたはEXPN SMTPコマンドをサポートしていないため、[RFC5321]のセクション7.3（「VRFY、EXPN、およびセキュリティ」）は電子メールの収集について説明しているため、MULEには適用されません。

Arguably, it is more difficult to cause an application-layer denial-of-service attack on a MULE server than on an SMTP server. This is partially due to the fact that ACP 142 is used in radio/wireless networks with relatively low bandwidth and very long round-trip time (especially if EMCON is in force). However, as MULE is using multicast, multiple MULE nodes can receive the same message and spend CPU resources processing it, even if the message is addressed to recipients that are not going to be handled by such nodes. As MULE lacks transport-layer source authentication, this can be abused by malicious senders.

間違いなく、SMTPサーバーよりもMULEサーバーでアプリケーション層のサービス拒否攻撃を引き起こすのは困難です。これは、ACP 142が比較的低い帯域幅と非常に長いラウンドトリップ時間（特にEMCONが有効な場合）の無線/ワイヤレスネットワークで使用されるという事実に一部起因します。ただし、MULEはマルチキャストを使用しているため、メッセージがそのようなノードで処理されない受信者宛てであっても、複数のMULEノードが同じメッセージを受信して、CPUリソースを処理することができます。 MULEにはトランスポート層のソース認証がないため、悪意のある送信者により悪用される可能性があります。

For security considerations related to use of zlib compression, see [RFC6713].

zlib圧縮の使用に関するセキュリティの考慮事項については、[RFC6713]を参照してください。

Due to the multicast nature of MULE, it cannot use TLS or DTLS. Accordingly, it does not support STARTTLS [RFC3207]. Users should not depend on hop-by-hop confidentiality or integrity protection of mail transferred among MULE MTAs (in the same way they can't generally rely on the use of STARTTLS on SMTP MTA-to-MTA links) and should consider the use of end-to-end protection, such as S/MIME [RFC5750] [RFC5751].

MULEのマルチキャストの性質により、TLSまたはDTLSを使用できません。したがって、STARTTLS [RFC3207]はサポートされていません。ユーザーは、MULE MTA間で転送されるメールのホップバイホップの機密性または整合性保護に依存すべきではなく（通常、SMTP MTAからMTAへのリンクでSTARTTLSの使用に依存できないのと同じように）、その使用を検討する必要があります。 S / MIME [RFC5750] [RFC5751]などのエンドツーエンド保護の。

S/MIME signatures and/or encryption survive gatewaying between MULE and SMTP environments.

S / MIME署名および/または暗号化は、MULE環境とSMTP環境の間のゲートウェイを通過します。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[ACP142A] CCEB, "P_Mul - A Protocol for Reliable Multicast in Bandwidth Constrained and Delayed Acknowledgement (EMCON) Environments", ACP 142(A), October 2008.

[ACP142A] CCEB、「P_Mul-帯域幅が制限された遅延確認応答（EMCON）環境での信頼性の高いマルチキャストのためのプロトコル」、ACP 142（A）、2008年10月。

[ITU.X690.2002] ITU-T, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, August 2015.

[ITU.X690.2002] ITU-T、「Information Technology-ASN.1 encoding rules：Specification of Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）and Distinguished Encoding Rules（DER）」、ITU-T Recommendation X .690、2015年8月。

[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, DOI 10.17487/RFC1870, November 1995, <https://www.rfc-editor.org/info/rfc1870>.

[RFC1870] Klensin、J.、Freed、N。、およびK. Moore、「メッセージサイズ宣言のためのSMTPサービス拡張」、STD 10、RFC 1870、DOI 10.17487 / RFC1870、1995年11月、<https：//www.rfc -editor.org/info/rfc1870>。

[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, DOI 10.17487/RFC1950, May 1996, <https://www.rfc-editor.org/info/rfc1950>.

[RFC1950] Deutsch、P. and J-L。 Gailly、「ZLIB Compressed Data Format Specification version 3.3」、RFC 1950、DOI 10.17487 / RFC1950、1996年5月、<https://www.rfc-editor.org/info/rfc1950>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, DOI 10.17487/RFC2852, June 2000, <https://www.rfc-editor.org/info/rfc2852>.

[RFC2852]ニューマン、D。、「Deliver By SMTP Service Extension」、RFC 2852、DOI 10.17487 / RFC2852、2000年6月、<https://www.rfc-editor.org/info/rfc2852>。

[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, DOI 10.17487/RFC3030, December 2000, <https://www.rfc-editor.org/info/rfc3030>.

[RFC3030] Vaudreuil、G。、「SMTP Service Extensions for Transmission of Large and Binary MIME Messages」、RFC 3030、DOI 10.17487 / RFC3030、12月、<https://www.rfc-editor.org/info/rfc3030> 。

[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, <https://www.rfc-editor.org/info/rfc3461>.

[RFC3461] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status Notifications（DSNs）」、RFC 3461、DOI 10.17487 / RFC3461、2003年1月、<https://www.rfc-editor.org / info / rfc3461>。

[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, <https://www.rfc-editor.org/info/rfc3464>.

[RFC3464] Moore、K。およびG. Vaudreuil、 "An Extensible Message Format for Delivery Status Notifications"、RFC 3464、DOI 10.17487 / RFC3464、2003年1月、<https://www.rfc-editor.org/info/rfc3464 >。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.

[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<https://www.rfc-editor.org/info/rfc5321>。

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.

[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https://www.rfc-editor.org/info/rfc5322>。

[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <https://www.rfc-editor.org/info/rfc5598>.

[RFC5598] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、DOI 10.17487 / RFC5598、2009年7月、<https://www.rfc-editor.org/info/rfc5598>。

[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, DOI 10.17487/RFC6152, March 2011, <https://www.rfc-editor.org/info/rfc6152>.

[RFC6152]クレンシン、J。、フリード、N。、ローズ、M。、およびD.クロッカー、編、「8ビットMIMEトランスポート用のSMTPサービス拡張」、STD 71、RFC 6152、DOI 10.17487 / RFC6152、3月2011、<https://www.rfc-editor.org/info/rfc6152>。

[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, <https://www.rfc-editor.org/info/rfc6522>.

[RFC6522] Kucherawy、M。、編、「メールシステム管理メッセージのレポート用のマルチパート/レポートメディアタイプ」、STD 73、RFC 6522、DOI 10.17487 / RFC6522、2012年1月、<https：//www.rfc -editor.org/info/rfc6522>。

[RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer Protocol Extension for Message Transfer Priorities", RFC 6710, DOI 10.17487/RFC6710, August 2012, <https://www.rfc-editor.org/info/rfc6710>.

[RFC6710] Melnikov、A。およびK. Carlberg、「メッセージ転送優先度のためのシンプルなメール転送プロトコル拡張」、RFC 6710、DOI 10.17487 / RFC6710、2012年8月、<https://www.rfc-editor.org/info/ rfc6710>。

[RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip' Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012, <https://www.rfc-editor.org/info/rfc6713>.

[RFC6713] Levine、J。、「「application / zlib」および「application / gzip」メディアタイプ」、RFC 6713、DOI 10.17487 / RFC6713、2012年8月、<https://www.rfc-editor.org/info / rfc6713>。

[RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015, <https://www.rfc-editor.org/info/rfc7601>.

[RFC7601] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 7601、DOI 10.17487 / RFC7601、2015年8月、<https://www.rfc-editor.org/info/rfc7601>。

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[STANAG-4406] NATO, "Military Message Handling System", STANAG 4406 Ed. 2, March 2005.

[STANAG-4406] NATO、「軍事メッセージ処理システム」、STANAG 4406 Ed。 2005年3月2日。

8.2. Informative References

8.2. 参考引用

[RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, DOI 10.17487/RFC1845, September 1995, <https://www.rfc-editor.org/info/rfc1845>.

[RFC1845] Crocker、D.、Freed、N。、およびA. Cargille、「SMTP Service Extension for Checkpoint / Restart」、RFC 1845、DOI 10.17487 / RFC1845、1995年9月、<https：//www.rfc-editor。 org / info / rfc1845>。

[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 1996, <https://www.rfc-editor.org/info/rfc2034>.

[RFC2034] Freed、N。、「拡張エラーコードを返すためのSMTPサービス拡張」、RFC 2034、DOI 10.17487 / RFC2034、1996年10月、<https://www.rfc-editor.org/info/rfc2034>。

[RFC2442] Freed, N., Newman, D., Belissent, J., and M. Hoy, "The Batch SMTP Media Type", RFC 2442, DOI 10.17487/RFC2442, November 1998, <https://www.rfc-editor.org/info/rfc2442>.

[RFC2442] Freed、N.、Newman、D.、Belissent、J。、およびM. Hoy、「The Batch SMTP Media Type」、RFC 2442、DOI 10.17487 / RFC2442、1998年11月、<https：//www.rfc -editor.org/info/rfc2442>。

[RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, September 2000, <https://www.rfc-editor.org/info/rfc2920>.

[RFC2920] Freed、N。、「コマンドパイプライン処理用のSMTPサービス拡張」、STD 60、RFC 2920、DOI 10.17487 / RFC2920、2000年9月、<https://www.rfc-editor.org/info/rfc2920>。

[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <https://www.rfc-editor.org/info/rfc3207>.

[RFC3207] Hoffman、P。、「Secure SMTP over Transport Layer SecurityのSMTPサービス拡張」、RFC 3207、DOI 10.17487 / RFC3207、2002年2月、<https://www.rfc-editor.org/info/rfc3207>。

[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, DOI 10.17487/RFC3865, September 2004, <https://www.rfc-editor.org/info/rfc3865>.

[RFC3865] Malamud、C。、「No Soliciting Simple Mail Transfer Protocol（SMTP）Service Extension」、RFC 3865、DOI 10.17487 / RFC3865、2004年9月、<https://www.rfc-editor.org/info/rfc3865 >。

[RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for Content Conversion", RFC 4141, DOI 10.17487/RFC4141, November 2005, <https://www.rfc-editor.org/info/rfc4141>.

[RFC4141] Toyoda、K. and D. Crocker、 "SMTP and MIME Extensions for Content Conversion"、RFC 4141、DOI 10.17487 / RFC4141、November 2005、<https://www.rfc-editor.org/info/rfc4141> 。

[RFC4405] Allman, E. and H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message", RFC 4405, DOI 10.17487/RFC4405, April 2006, <https://www.rfc-editor.org/info/rfc4405>.

[RFC4405] Allman、E。およびH. Katz、「電子メールメッセージの責任ある提出者を示すためのSMTPサービス拡張」、RFC 4405、DOI 10.17487 / RFC4405、2006年4月、<https：//www.rfc-editor .org / info / rfc4405>。

[RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, DOI 10.17487/RFC4468, May 2006, <https://www.rfc-editor.org/info/rfc4468>.

[RFC4468]ニューマン、C。、「Message Submission BURL Extension」、RFC 4468、DOI 10.17487 / RFC4468、2006年5月、<https://www.rfc-editor.org/info/rfc4468>。

[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, <https://www.rfc-editor.org/info/rfc4954>.

[RFC4954] Siemborski、R.、Ed。 A. Melnikov編、「認証用のSMTPサービス拡張」、RFC 4954、DOI 10.17487 / RFC4954、2007年7月、<https://www.rfc-editor.org/info/rfc4954>。

[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, <https://www.rfc-editor.org/info/rfc5750>.

[RFC5750] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Certificate Handling」、RFC 5750、DOI 10.17487 / RFC5750、2010年1月、<https：//www.rfc- editor.org/info/rfc5750>。

[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>.

[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<https：//www.rfc- editor.org/info/rfc5751>。

[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <https://www.rfc-editor.org/info/rfc6409>.

[RFC6409] Gellens、R。およびJ. Klensin、「メールのメッセージ送信」、STD 72、RFC 6409、DOI 10.17487 / RFC6409、2011年11月、<https://www.rfc-editor.org/info/rfc6409> 。

[RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid-Since Header Field and SMTP Service Extension", RFC 7293, DOI 10.17487/RFC7293, July 2014, <https://www.rfc-editor.org/info/rfc7293>.

[RFC7293] Mills、W。およびM. Kucherawy、「Require-Recipient-Valid-SinceヘッダーフィールドとSMTPサービス拡張」、RFC 7293、DOI 10.17487 / RFC7293、2014年7月、<https：//www.rfc-editor .org / info / rfc7293>。

Acknowledgements

謝辞

Thank you to Steve Kille for suggestions, comments, and corrections on this document. An additional thank you goes to Barry Leiba, Sean Turner, Dave Crocker, and Nick Hudson for reviews and comments on this document.

このドキュメントに対する提案、コメント、および訂正を行ったSteve Killeに感謝します。このドキュメントのレビューとコメントを提供してくれたBarry Leiba、Sean Turner、Dave Crocker、Nick Hudsonに感謝します。

Some text was borrowed from "P_Mul: An Application Protocol for the Transfer of Messages over Multicast Subnetworks and under EMCON Restrictions" (September 1997); we gratefully acknowledge the work of the authors of that document.

「P_Mul：マルチキャストサブネットワーク上およびEMCONの制限の下でのメッセージ転送のためのアプリケーションプロトコル」（1997年9月）から一部のテキストが借用されました。その文書の著者の仕事に感謝します。

Authors' Addresses

著者のアドレス

David Wilson Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom

David Wilson Isode Ltd 14 Castle Mewsハンプトン、ミドルセックスTW12 2NPイギリス

   Email: David.Wilson@isode.com

Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom

Alexey Melnikov（編集者）Isode Ltd 14 Castle Mewsハンプトン、ミドルセックスTW12 2NPイギリス

   Email: Alexey.Melnikov@isode.com