RFC 6152 - SMTP Service Extension for 8-bit MIME Transport 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6152
タイトル : RFC 6152 - 8ビットMIMEトランスポートのSMTPサービス拡張
翻訳編集 : 自動生成

[要約] RFC 6152は、SMTPサービス拡張である8ビットMIMEトランスポートに関するものです。その目的は、SMTPプロトコルを使用して8ビットデータを送信するための標準化とサポートを提供することです。

Internet Engineering Task Force (IETF)                        J. Klensin
Request for Comments: 6152
STD: 71                                                         N. Freed
Obsoletes: 1652                                                   Oracle
Category: Standards Track                                        M. Rose
ISSN: 2070-1721                             Dover Beach Consulting, Inc.
                                                         D. Crocker, Ed.
                                             Brandenburg InternetWorking
                                                              March 2011

SMTP Service Extension for 8-bit MIME Transport

8ビットMIMEトランスポートのSMTPサービス拡張

Abstract

概要

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP.

このメモは、SMTPサービスの拡張機能を定義します。これにより、SMTPコンテンツ本体は、SMTPを使用してUS-ASCIIオクテット範囲（16進数00〜7F）の外側のオクテットを含むテキストで構成されるものです。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これは、インターネット標準トラックドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。

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

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6152で取得できます。

著作権表示

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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

1. Introduction

1. はじめに

Although SMTP is widely and robustly deployed, various extensions have been requested by parts of the Internet community. In particular, a significant portion of the Internet community wishes to exchange messages in which the content body consists of a MIME message [RFC2045][RFC2046][RFC5322] containing arbitrary octet-aligned material. This memo uses the mechanism described in the SMTP specification [RFC5321] to define an extension to the SMTP service whereby such contents may be exchanged. Note that this extension does NOT eliminate the possibility of an SMTP server limiting line length; servers are free to implement this extension but nevertheless set a line length limit no lower than 1000 octets. Given that this restriction still applies, this extension does NOT provide a means for transferring unencoded binary via SMTP.

SMTPは広く堅牢に展開されていますが、インターネットコミュニティの一部からさまざまな拡張機能が要求されています。特に、インターネットコミュニティの大部分は、コンテンツ本体がMIMEメッセージ[RFC2045] [RFC2046] [RFC5322]で構成されているメッセージを交換したいと考えています。このメモは、SMTP仕様[RFC5321]で説明されているメカニズムを使用して、そのような内容が交換される可能性のあるSMTPサービスの拡張を定義します。この拡張機能は、SMTPサーバーが線の長さを制限する可能性を排除しないことに注意してください。サーバーはこの拡張機能を自由に実装できますが、それにもかかわらず、ラインの長さ制限を1000オクテット以上に設定します。この制限が依然として適用されることを考えると、この拡張機能は、SMTPを介して非エンコードされたバイナリを転送する手段を提供しません。

2. Framework for the 8-bit MIME Transport Extension

2. 8ビットMIMEトランスポートエクステンションのフレームワーク

The 8-bit MIME transport extension is laid out as follows:

8ビットMIMEトランスポートエクステンションは次のようにレイアウトされています。

1. the name of the SMTP service extension defined here is 8bit-MIMEtransport;

1. ここで定義されているSMTPサービス拡張機能の名前は8ビット照合ポートです。

2. the EHLO keyword value associated with the extension is 8BITMIME;

2. 拡張機能に関連付けられているEhloキーワード値は8bitmimeです。

3. no parameter is used with the 8BITMIME EHLO keyword;

3. 8bitmime Ehloキーワードではパラメーターは使用されていません。

4. one optional parameter using the keyword BODY is added to the MAIL command. The value associated with this parameter is a keyword indicating whether a 7-bit message (in strict compliance with [RFC5321]) or a MIME message (in strict compliance with [RFC2046] and [RFC2045]) with arbitrary octet content is being sent. The syntax of the value is as follows, using the ABNF notation of [RFC5234]:

4. キーワード本文を使用した1つのオプションパラメーターがメールコマンドに追加されます。このパラメーターに関連付けられた値は、任意のオクテット含有量を使用した7ビットメッセージ（[RFC5321]に厳密に準拠している）またはMIMEメッセージ（[RFC2046]および[RFC2045]を厳密に準拠している）が送信されているかどうかを示すキーワードです。[RFC5234]のABNF表記を使用して、値の構文は次のとおりです。

       body-value = "7BIT" / "8BITMIME"

5. no additional SMTP verbs are defined by this extension; and

5. この拡張機能によって追加のSMTP動詞は定義されていません。と

6. the next section specifies how support for the extension affects the behavior of a server and client SMTP.

6. 次のセクションでは、拡張機能のサポートがサーバーとクライアントSMTPの動作にどのように影響するかを指定します。

3. The 8bit-MIMEtransport Service Extension

3. 8bit-MimeTransportサービス拡張機能

When a client SMTP wishes to submit (using the MAIL command) a content body consisting of a MIME message containing arbitrary lines of octet-aligned material, it first issues the EHLO command to the server SMTP. If the server SMTP responds with code 250 to the EHLO command, and the response includes the EHLO keyword value 8BITMIME, then the server SMTP is indicating that it supports the extended MAIL command and will accept MIME messages containing arbitrary octet-aligned material.

クライアントSMTPが（メールコマンドを使用）（メールコマンドを使用）したい場合、Octetに配置された素材の任意の行を含むMIMEメッセージで構成されるコンテンツ本体を希望する場合、最初にEhloコマンドをサーバーSMTPに発行します。サーバーSMTPがコード250でEHLOコマンドに応答し、応答がEHLOキーワード値8Bitmimeを含む場合、サーバーSMTPは拡張メールコマンドをサポートし、任意のオクテット並列素材を含むMIMEメッセージを受け入れることを示しています。

The extended MAIL command is issued by a client SMTP when it wishes to transmit a content body consisting of a MIME message containing arbitrary lines of octet-aligned material. The syntax for this command is identical to the MAIL command in RFC 5321, except that a BODY parameter must appear after the address. Only one BODY parameter may be used in a single MAIL command.

拡張メールコマンドは、オクテット並列材料の任意の行を含むMIMEメッセージで構成されるコンテンツ本体を送信したい場合、クライアントSMTPによって発行されます。このコマンドの構文は、RFC 5321のメールコマンドと同一ですが、ボディパラメーターがアドレスの後に表示される必要があることを除きます。単一のメールコマンドで使用できるボディパラメーターは1つだけです。

The complete syntax of this extended command is defined in RFC 5321. The esmtp-keyword is BODY, and the syntax for esmtp-value is given by the syntax for body-value shown above.

この拡張コマンドの完全な構文はRFC 5321で定義されています。ESMTPキーワードは本体であり、ESMTP値の構文は上記のボディ値の構文によって与えられます。

The value associated with the BODY parameter indicates whether the content body that will be passed using the DATA command consists of a MIME message containing some arbitrary octet-aligned material ("8BITMIME") or is encoded entirely in accordance with RFC 5321 ("7BIT").

ボディパラメーターに関連付けられている値は、データコマンドを使用して渡されるコンテンツ本体が、任意のオクテット整列素材（「8ビットマイム」）を含むMIMEメッセージで構成されているか、RFC 5321（「7ビット」に従って完全にエンコードされているかどうかを示します。）。

A server that supports the 8-bit MIME transport service extension shall preserve all bits in each octet passed using the DATA command. Naturally, the usual SMTP data-stuffing algorithm applies, so that a content that contains the five-character sequence of <CR> <LF> <DOT> <CR> <LF> or a content that begins with the three-character sequence of <DOT> <CR> <LF> does not prematurely terminate the transfer of the content. Further, it should be noted that the CR-LF pair immediately preceding the final dot is considered part of the content. Finally, although the content body contains arbitrary lines of octet-aligned material, the length of each line (number of octets between two CR-LF pairs) is still subject to SMTP server line length restrictions (which can allow as few as 1000 octets, inclusive of the CR-LF pair, on a single line). This restriction means that this extension provides the necessary facilities for transferring a MIME object with the 8BIT content-transfer-encoding, it DOES NOT provide a means of transferring an object with the BINARY content-transfer-encoding.

8ビットMIMEトランスポートサービス拡張機能をサポートするサーバーは、データコマンドを使用して通過した各オクテットのすべてのビットを保持するものとします。当然のことながら、通常のSMTPデータスタッフアルゴリズムが適用されるため、<cr> <lf> <lf> <dot> <cr> <lf>の5文字のシーケンスを含むコンテンツまたは3文字のシーケンスから始まるコンテンツが含まれます。<dot> <cr> <lf>は、コンテンツの転送を早めに終了しません。さらに、最終ドットの直前のCR-LFペアは、コンテンツの一部と見なされることに注意する必要があります。最後に、コンテンツ本体にはオクテット並列材料の任意の線が含まれていますが、各ラインの長さ（2つのCR-LFペアの間のオクテットの数）には、SMTPサーバーラインの長さの制限（わずか1000オクテットを許可できます）CR-LFペアを含む、単一の行に）。この制限は、この拡張機能が8ビットのコンテンツ移動エンコードでMIMEオブジェクトを転送するために必要な機能を提供することを意味します。これは、バイナリコンテンツ転移エンコードでオブジェクトを転送する手段を提供しません。

Once a server SMTP supporting the 8bit-MIMEtransport service extension accepts a content body containing octets with the high-order (8th) bit set, the server SMTP must deliver or relay the content in such a way as to preserve all bits in each octet.

8bit-Mimetransport Service拡張機能をサポートするサーバーSMTPが、高次（8）ビットセットを備えたオクテットを含むコンテンツ本体を受け入れると、サーバーSMTPは各オクテットのすべてのビットを保存するような方法でコンテンツを配信またはリレーする必要があります。

If a server SMTP does not support the 8-bit MIME transport extension (either by not responding with code 250 to the EHLO command, or by not including the EHLO keyword value 8BITMIME in its response), then the client SMTP must not, under any circumstances, attempt to transfer a content that contains characters outside of the US-ASCII octet range (hex 00-7F).

サーバーSMTPが8ビットMIMEトランスポートエクステンションをサポートしていない場合（Ehloコマンドにコード250を使用しないか、EHLOキーワード値8Bitmimeをその応答に含めないことで）状況は、US-ASCIIオクテット範囲（16進数00〜7F）の外側に文字を含むコンテンツを転送しようとします。

A client SMTP has two options in this case: first, it may implement a gateway transformation to convert the message into valid 7-bit MIME, or second, it may treat the barrier to 8-bit as a permanent error and handle it in the usual manner for delivery failures. The specifics of the transformation from 8-bit MIME to 7-bit MIME are not described by this RFC; the conversion is nevertheless constrained in the following ways:

この場合、クライアントSMTPには2つのオプションがあります。1つ目は、メッセージを有効な7ビットMIMEに変換するためにゲートウェイ変換を実装するか、2番目に、障壁を8ビットに恒久的なエラーとして扱い、それを処理することができます。配達障害の通常の方法。8ビットMIMEから7ビットMIMEへの変換の詳細は、このRFCでは説明されていません。それにもかかわらず、変換は次の方法で制約されています。

1. it must cause no loss of information; MIME transport encodings must be employed as needed to insure this is the case, and

1. 情報の損失を引き起こさない必要があります。これが事実であることを保証するために、必要に応じてマイム輸送エンコーディングを採用する必要があり、

2. the resulting message must be valid 7-bit MIME.

2. 結果のメッセージは、有効な7ビットMIMEでなければなりません。

4. Usage Example

4. 使用例

The following dialogue illustrates the use of the 8bit-MIMEtransport service extension:

次のダイアログは、8bit-Mimetransportサービス拡張機能の使用を示しています。

   S: <wait for connection on TCP port 25>
   C: <open connection to server>
   S: 220 dbc.mtview.ca.us SMTP service ready
   C: EHLO ymir.claremont.edu
   S: 250-dbc.mtview.ca.us says hello
   S: 250 8BITMIME
   C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
   S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
   C: RCPT TO:<mrose@dbc.mtview.ca.us>
   S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
   C: DATA
   S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
    ...
   C: .
   S: 250 OK
   C: QUIT
   S: 250 Goodbye

5. Security Considerations

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

This RFC does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail and present in fully conforming implementations of RFC 5321, including attacks facilitated by the presence of an option negotiation mechanism. Since MIME semantics are transport-neutral, the 8BITMIME option provides no more added capability to disseminate malware than is provided by unextended 7-bit SMTP.

このRFCはセキュリティの問題について議論せず、電子メールでまだ風土病ではなく、RFC 5321の完全に適合する実装に存在するセキュリティの問題を提起するとは考えられていません。MIMEセマンティクスは輸送中立であるため、8Bitmimeオプションは、拡張された7ビットSMTPによって提供されるよりも、普及するマルウェアに追加の機能を提供しません。

6. IANA Considerations

6. IANAの考慮事項

6.1. SMTP Service Extension Registration

6.1. SMTPサービス拡張登録

This document defines an SMTP and Submit service extension. IANA has updated the 8BITMIME entry in the SMTP Service Extensions registry, as follows:

このドキュメントでは、SMTPを定義し、サービス拡張子を送信します。IANAは、次のように、SMTP Service Extensionsレジストリの8Bitmimeエントリを更新しました。

Keyword: 8BITMIME

キーワード：8bitmime

Description: SMTP and Submit transport of 8-bit MIME content

説明：SMTPと8ビットMIMEコンテンツの輸送を提出する

Reference: [RFC6152]

参照：[RFC6152]

Parameters: See Section 2 in this specification.

パラメーター：この仕様のセクション2を参照してください。

7. Acknowledgements

7. 謝辞

E. Stefferud was an original author. This version of the specification was produced by the YAM working group.

E. Stefferudは元の著者でした。仕様のこのバージョンは、ヤムワーキンググループによって作成されました。

Original acknowledgements: This document represents a synthesis of the ideas of many people and reactions to the ideas and proposals of others. Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas and text sufficient to be considered co-authors. Other important suggestions, text, or encouragement came from Harald Alvestrand, Jim Conklin, Mark Crispin, Frank da Cruz, Olafur Gudmundsson, Per Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John Wagner, Rayan Zachariassen, and the contributions of the entire IETF SMTP Working Group. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here. Indeed, in some cases, the response to a particular criticism was to accept the problem identification but to include an entirely different solution from the one originally proposed.

元の謝辞：この文書は、多くの人々のアイデアの統合と、他の人のアイデアや提案に対する反応を表しています。Randall Atkinson、Craig Everhart、Risto Kankkunen、Greg Vaudreuilは、共著者と見なされるのに十分なアイデアとテキストを提供しました。その他の重要な提案、テキスト、または励ましは、ハラルド・アルベスランド、ジム・コンクリン、マーク・クリスピン、フランク・ダ・クルス、オラファー・グドムンドソン、ヘドランド、クリスチャン・フイトマ、ニール・カティン、エリオット・リア、ハロルド・A・ミラー、キース・ムーア、ダン・オスカーソン、ジュリアンから来ました。オニオン、ニール・リッカート、ジョン・ワグナー、ラヤン・ザカリセン、およびIETF SMTPワーキンググループ全体の貢献。もちろん、ここに示されているアイデアの組み合わせに対して必ずしも責任者はいません。実際、場合によっては、特定の批判に対する対応は、問題の識別を受け入れることであったが、最初に提案されたものとはまったく異なる解決策を含めることでした。

8. Normative References

8. 引用文献

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。

[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.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。

Authors' Addresses

著者のアドレス

John C. Klensin 1770 Massachusetts Ave, Ste. 322 Cambridge, MA 02140 USA

ジョン・C・クレンシン1770マサチューセッツアベニュー、Ste。322ケンブリッジ、マサチューセッツ州02140 USA

   Phone: +1 617 245 1457
   EMail: john+ietf@jck.com

Ned Freed Oracle 800 Royal Oaks Monrovia, CA 91016-6347 USA

Ned Freed Oracle 800 Royal Oaks Monrovia、CA 91016-6347 USA

   EMail: ned.freed@mrochek.com

M. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 USA

M. Rose Dover Beach Consulting、Inc。POB 255268 Sacramento、CA 95865-5268 USA

   Phone: +1 916 538 2535
   EMail: mrose17@gmail.com

D. Crocker (editor) Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA USA

D.クロッカー（編集者）ブランデンブルクインターネットワーキング675スプルース博士サニーベール、カリフォルニア州アメリカ

   Phone: +1 408 246 8253
   EMail: dcrocker@bbiw.net
   URI:   http://bbiw.net