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

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

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

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.

このメモは、US-ASCIIオクテット範囲（16進数00〜7F）の外のオクテットを含むテキストからなるSMTPコンテンツ本体がSMTPを使用して中継することができることにより、SMTPサービスへの拡張を定義します。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

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

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

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

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6152で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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サービスの拡張を定義するためにSMTP仕様[RFC5321]で説明されたメカニズムを使用します。この拡張機能は、行の長さを制限するSMTPサーバの可能性を排除しないことに注意してください。サーバは、この拡張機能を実装するのは自由ですが、それにもかかわらず、1000個のオクテットより低く行の長さの制限を設定します。この制限はまだ適用されることを考えると、この拡張機能は、SMTP経由でエンコードされていないバイナリを転送するための手段を提供していません。

2. Framework for the 8-bit MIME Transport Extension

8ビットMIME転送拡張2.フレームワーク

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ビット・MIMEtransportです。

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]:

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

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

ボディ-値= "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. 8ビット・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は（MAILコマンドを使用して）オクテット整列材料の任意の行を含むMIMEメッセージからなるコンテンツ本体を送信したい場合、それが最初のサーバにSMTP EHLOコマンドを発行します。サーバSMTPがEHLOコマンドにコード250で応答し、応答が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メッセージからなるコンテンツ本体を送信したい場合、拡張MAILコマンドは、クライアントSMTPによって発行されます。このコマンドの構文は、BODYパラメータはアドレスの後に現れなければならないことを除いて、RFC 5321でMAILコマンドと同じです。一つだけBODYパラメータは、単一のMAILコマンドで使用することができます。

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.

この拡張コマンドの完全な構文は、ESMTPキーワードは、本体であるRFC 5321.に定義され、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").

身体パラメータに関連する値は、DATAコマンドを使用して渡されるコンテンツ本体は、いくつかの任意のオクテット整列材料を含むMIMEメッセージ（「8BITMIME」）からなるか、またはRFC 5321（「7BIT」に応じて完全に符号化されているかどうかを示します）。

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転送サービス拡張をサポートするサーバは、DATAコマンドを使用して渡さ。当然のことながら、通常のSMTPデータ・スタッフィングアルゴリズムが適用され、<CR> <LF> <DOT> <CR> <LF>の5文字列が含まれているコンテンツまたはの3文字列で始まるコンテンツように<DOT> <CR> <LF>は早期コンテンツの転送を終了しません。さらに、直ちに最終ドットに先行するCR-LFペアがコンテンツの一部とみなされることに留意すべきです。コンテンツ本体がオクテット整列材料の任意の行が含まれているが、最終的に、各ラインの長さ（2 CR-LFペア間のオクテットの数）は、依然としてわずか1000オクテットを可能にすることができる（SMTPサーバーの行の長さの制限が適用され）単一の行に、CR-LFペアを含みます。この制限は、この拡張は、8BITコンテンツ転送エンコードで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.

8ビット・MIMEtransportサービス拡張をサポートするサーバ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を含めないことによってのいずれか）をサポートしていない場合、クライアントSMTPはならず、任意の下状況は、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つのオプションがあり：第一に、それは有効な7ビットMIMEにメッセージを変換するゲートウェイ変換を実装することができる、又は第二、それは永久的なエラーとして8ビットに障壁を治療し、それを処理することができます配信の失敗のための通常の方法。 7ビットMIME 8ビット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.それは、情報の損失を引き起こしてはなりません。このような場合は保証するために必要なMIME輸送エンコーディングを使用しなければならない、と

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:

以下の対話は8ビット・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

Sは：<サーバーへのオープン接続> S：220 dbc.mtview.ca.usのSMTPサービス準備C：EHLO ymir.claremont.edu S：250-dbc.mtview.ca C <TCPポート25で接続を待ちます>。 FROM MAIL：250 8BITMIME C：<ned@ymir.claremont.edu> BODY = 8BITMIME S：250 <ned@ymir.claremont.edu> ...送信者と8BITMIME OK C：RCPT TO：<mroseたちはハローS語ります@ dbc.mtview.ca.us> S：250 <mrose@dbc.mtview.ca.us> ...受信者OK C：DATA S：354 CRLF.CRLFで終わる、8BITMIMEメッセージを送信します。 ... C：。 S：250 OK C：QUIT S：250さようなら

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サービス拡張レジストリで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は原作者でした。仕様のこのバージョンはYAMワーキンググループによって作成されました。

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.

オリジナル謝辞：この文書では、他人のアイデアや提案に多くの人々との反応のアイデアの合成を表しています。ランドール・アトキンソン、クレイグ・エバハート、のRisto Kankkunen、とグレッグボードルイは、共著者とみなされるために十分なアイデアとテキストを寄付しました。その他の重要な提案、テキスト、または励ましはハラルドAlvestrand、ジム・コンクリン、マーク・クリスピン、フランク・ダ・クルス、オラフルグドムンソン、パーHedeland、クリスチャンHuitma、ニールKATIN、エリオット・リア、ハロルドA. Miller氏、キースムーア、ダンOscarsson、ジュリアンから来ましたタマネギ、ニールRickert、ジョン・ワグナー、ライアンZachariassen、全体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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。

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

[RFC2046]解放され、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]クロッカー、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.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。

Authors' Addresses

著者のアドレス

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

ジョンC。 1770年マサチューセッツアベニュー、マリーClensin。 322ケンブリッジ、MA 02140彼

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

電話：+1 617 245 1457 Eメール：john+ietf@jck.com

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

ネッドフリードオラクル800のロイヤルオークスモンロビア、カリフォルニア州91016から6347 USA

EMail: ned.freed@mrochek.com

メールアドレス：ned.freed@mrochek.com

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

M.バラドーバービーチコンサルティング株式会社POB 255268サクラメント、CA 95865から5268 USA

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

電話：+1 916 538 2535 Eメール：mrose17@gmail.com

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

D.クロッカー（エディタ）ブランデンブルクインターネットワーキング675スプルース博士はカリフォルニア州サニーベールUSA

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

電話：+1 408 246 8253 Eメール：dcrocker@bbiw.net URI：http://bbiw.net