が原著です。 翻訳版は、翻訳からくる間違いがあり得ます。 Yasutaka Kato 加藤泰孝 ----------------------------------------------------------------------  rfc1652 Network Working Group J. Klensin, WG Chair Request for Comments: 1652 MCI Obsoletes: 1426 N. Freed, Editor Category: Standards Track Innosoft M. Rose Dover Beach Consulting, Inc. E. Stefferud Network Management Associates, Inc. D. Crocker Silicon Graphics, Inc. July 1994 SMTP Service Extension for 8bit-MIMEtransport SMTPサービスの8bit-MIME転送への拡張 この覚書の位置付け この文書はインターネット交流社会のためのインターネット標準過程手順を 特定し、改善への議論と示唆を求めるものです。この手順の標準化状況と位 置付けについては「インターネット公的手順基準」 (STD1) の最新の編集を 参照ください。この覚書の配布の制限はありません。 要約 この覚書は、US-ASCIIオクテック範囲 (hex 00-7F) 外のオクテックを内容 としているテキストから構成されていSMTP内容ボディが、SMTP使用の際、中 継されるかもしれないところの、SMTPサービスの拡張を定義します。 1. はじめに SMTPは広く活発に採用されていますが、様々な拡張がインターネット交流社 会のあちこちから要求されてきました。特に、インターネット交流社会の有 意義な立場から、任意のオクテック-配列素材を内容としているMIMEメッ セージ [3] から、内容ボディが構成されているメッセージを交換したい望 まれています。この覚書は、そのような内容が交換されるかもしれない SMTPサービスに拡張を定義するために、[5] で記載されている機構を使って います。この拡張はSMTPサービス行長制限機能を除いていません;サーバー は自由にこの拡張を装備しますが、けれども 1000 オクテックを越えない行 長制限を設定します。やはりこの制限が摘要されるので、この拡張はSMTP経 由で符号化されていないバイナリーの転送手段を提供していません。 Klensin, Freed, Rose, Stefferud & Crocker [Page 1]  RFC 1652 SMTP 8bit-MIMEtransport July 1994 2. 8ビットMIME転送拡張の枠組 8ビットMIME転送拡張は、以下のように整えられています: (1) ここで定義されたSMTPサービス拡張は、8ビットMIME転送 (8bit- MIMEtransport) です; (2) 拡張と協調するEHLOキワード値は、8BITMIMEです; (3) パラメーターは、8BITMIME EHLOキーワードで使用されません; (4) キワードボディを使った選択性 (任意) のパラメーターが、メール FROM命令に追加されます。このパラメーターと協調する値は、任意 のオクテット内容の7ビットメッセージ ([1]と厳格に従う) もしく はMIMEメッセージ ([1]と厳格に従う) が送信されることを示唆す るキワードです。この値の構文は、[2]のABNF命名法を使って、以 下のようになります: body-value ::= "7BIT" / "8BITMIME" (5) 如何なる追加SMTP動詞もこの拡張で定義されていません:そして (6) 次のセクションが、この拡張のサポートはサーバーとクライアント SMTPの振る舞いにどのように作用するか、を特定します。 3. 8ビットMIME転送サービス拡張 クライアントSMTPが、オクテック配列素材の任意の行を内容とするMIMEメッ セージから構成される内容ボディを、転送 (メール命令を使って) したい場 合、最初にEHLO命令をサーバーSMTPに発します。サーバーSMTPがコード250 でEHLO命令に応答しその反応がEHLOキワード値8BITMIMEを含んでいれば、次 いでサーバーSMTPは、それは拡張されたメール命令をサポートし、オクテッ ク配列素材の任意の行を内容とするMIMEメッセージを受け入れることを示唆 しています。 拡張メール命令は、オクテック配列素材の任意の行を内容とするMIMEメッ セージから構成される内容ボディを転送したい場合、クライアントSMTPに よって出されます。この命令の構文は [1]のメール命令と同じで、ボディパ ラメーターがアドレスの後にくることがちがいますが。唯一つのボディパラ メーターが単一メール命令で使用されるかもしれません。 Klensin, Freed, Rose, Stefferud & Crocker [Page 2]  RFC 1652 SMTP 8bit-MIMEtransport July 1994 この拡張命令の完全な構文は [5] で定義されています。esmtp-keyword は ボディでesmtp-value の構文は上に示されたbody-valueによって与えられま す。 ボディパラメーターと協調する値は、DATA命令を使って渡される内容ボディ が任意のオクテック-配列素材を内容としているMIMEメッセージ ("8BITMIME") から構成されているかもしくは[1] ("7BIT") に従って全体が符号化されて いるか、を示唆します。 8ビットMIME転送サービス拡張をサポートしているサーバーは、DATA命令を 使って渡された各オクテックの全てのビットを保存します (shall) 。 当然、普通のSMTPデーター詰め込みアルゴリスムが摘要され、以下の五つの 文字を含んでいる内容、 もしくは以下の三つの文字で始まる内容 は、内容の転送を早まって終了しません。さらに、最終ドットに先行する CDLF組は内容の一部と考えられることが注意されるべきです。最後に、内容 ボディはオクテット-配列素材の任意の行を内容としていますが、各行の長 さ (二つのCFLFの間のオクテット数) はなおSMTPサーバー行長制限 (単一行 で1000オクテット以下なら許容されまるかもしれない) の対象です。この制 限は、この拡張は8ビット内容転送符号化でMIME対象を転送するに必要な機能 を提供しているかもしれなく、バイナリー内容転送符号化で対象を転送する 手段を提供していないことを、意味しています。 8ビット-MIME転送サービス拡張をサーバーSMTPが一旦高序列 (8ビット) の オクテットを含んでいる内容ボディを受け入れると、サーバーSMTPは各オク テットの全てのビットを保存する方法で内容を配達もしくは中継しなければ なりません。 サーバーSMTPが8ビット-MIME転送拡張をサポートしていない (コード250で EHLO命令に応答しないかもしくはその応答にEHLOキワード値8BITMIMEを含ん でいないかのどちらかで) なら、クライアントSMTPは、如何なる環境のもと でも、US-ASCIIオクテット範囲 (hex 00-7F) 外の文字を含む内容を転送する よう試みてはいけません。 クライアントSMTPはこの場合二つの選択肢を持っています:最初に、その メッセージを正しい7ビットMIMEに変換するようゲートウェイ転送を装備す るかもしれません、もしくは二番目としてパラメーター間違いとしてこれを Klensin, Freed, Rose, Stefferud & Crocker [Page 3]  RFC 1652 SMTP 8bit-MIMEtransport July 1994 処理し通常のやり方で配達失敗としてそれを取り扱うかもしれません。8 ビットMIMEから7ビットMIMEへの転送使用はこのRFCに記載されていません; この変換は、以下の方法で、強制されます: (1) それは情報の損失を何らおこしてはなりません;MIME転送符号化 が、このケースであり、そして (2) その結果のメッセージは、正しい7ビットMIMEでああるとの保証が 要求されるなら、採用されなければなりません。 4. 使用事例 以下の対話は、8ビット-MIMEサービス拡張の使用を図解しています: S: C: 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: BODY=8BITMIME S: 250 ... Sender and 8BITMIME ok C: RCPT TO: S: 250 ... Recipient ok C: DATA S: 354 Send 8BITMIME message, ending in CRLF.CRLF. ... C: . S: 250 OK C: QUIT S: 250 Goodbye 5. 安全性への配慮 このRFCは安全性問題を議論してなく、電子メールですでに固有でない安全 問題を生じたり、[1]の十分に適合している装備で起こすとは考えていませ ん。 6. 謝辞 この文書は、多くの人達のアイデアとそのアイデアへの反応と別の人の提案 の集大成を表わしたものです。Randall Atkinson・Craig Everhart・Risto KankkunenそしてGreg Vaudreuil氏は、共著者とも言えるにふさわしいアイ デアと文章を与えてくれました。その他の重要な示唆や文章や励ましが、 Harald Alvestrand・Jim Conklin・Mark Crispin・Frank da Cruz・'Olafur Gudmundsson・Per Hedeland・Christian Huitma・Neil Katin・Eliot Lear・ Klensin, Freed, Rose, Stefferud & Crocker [Page 4]  RFC 1652 SMTP 8bit-MIMEtransport July 1994 Harold A.Miller・Keith Moore・Dan Oscarsson・Julian Onions・Neil Rickert・John Wagner・Rayan ZachariassenそしてIETF SMTP Working Group の参加者から届きました。勿論、個人がここに代表されたアイデアの 集大成の責任を取る必要はありません。実際、ケースによっては、特殊な批 判への反応は問題同一視を認めることですが、オリジナルに提案されたもの とは全く異なる解決を含むこともありました。 7. 参照 (References) [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, September 1993. [4] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1522, University of Tennessee, September 1993. [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., Silicon Graphics, Inc., July 1994. [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, BBN, January 1986. 8. 座長・編集者そして著者への連絡 John Klensin, WG Chair MCI Data Services Division 2100 Reston Parkway, 6th floor Reston, VA 22091 USA Phone:: 1 703 715 7361 Fax: +1 703 715 7435 EMail: klensin@mci.net Klensin, Freed, Rose, Stefferud & Crocker [Page 5]  RFC 1652 SMTP 8bit-MIMEtransport July 1994 Ned Freed, Editor Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA Phone:: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Moutain View, CA 94043-2186 USA Phone: +1 415 968 1052 Fax: +1 415 968 2510 EMail: mrose@dbc.mtview.ca.us Einar A. Stefferud Network Management Associates, Inc. 17301 Drey Lane Huntington Beach, CA, 92647-5615 USA Phone: +1 714 842 3711 Fax: +1 714 848 2091 EMail: stef@nma.com Dave Crocker Silicon Graphics, Inc. 2011 N. Shoreline Blvd. P.O. Box 7311 Mountain View, CA 94039 USA Phone: +1 415 390 1804 Fax: +1 415 962 8404 EMail: dcrocker@sgi.com Klensin, Freed, Rose, Stefferud & Crocker [Page 6]