RFC1652 日本語訳
1652 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N.Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. (Format: TXT=11842 bytes) (Obsoletes RFC1426) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループJ.Klensin、コメントを求めるWG議長Requestをネットワークでつないでください: 1652年のMCIは以下を時代遅れにします。 1426年の解放されたN.エディタカテゴリ: Inc.D.医者シリコングラフィックス1994年7月にInc.E.Stefferudネットワークマネージメント関連に相談する標準化過程Innosoft M.バラドーヴァービーチ
SMTP Service Extension for 8bit-MIMEtransport
8ビット-MIMEtransportのためのSMTPサービス拡張子
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このメモは米国のASCII八重奏範囲(十六進法00-7F)の外に八重奏を含むテキストから成るSMTPの満足しているボディーがSMTPを使用することでリレーされるかもしれないSMTPサービスと拡大を定義します。
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 [3] containing arbitrary octet-aligned material. This memo uses the mechanism described in [5] 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メッセージ[3]から成るメッセージを交換するというインターネットコミュニティ願望の重要な部分。 このメモはそのようなコンテンツが交換されるかもしれないSMTPサービスと拡大を定義するために[5]で説明されたメカニズムを使用します。 この拡大がSMTPサーバーが行長を制限する可能性を排除しないことに注意してください。 この拡大を実行しますが、それにもかかわらず、サーバは無料で1000の八重奏より低く行長限界を設定できません。 この制限がまだ適用されているなら、この拡大はSMTPを通して暗号化されていないバイナリーを移すための手段を提供しません。
Klensin, Freed, Rose, Stefferud & Crocker [Page 1] RFC 1652 SMTP 8bit-MIMEtransport July 1994
解放されたKlensinは上昇して、Stefferudとクロッカー[1ページ]RFC1652SMTP8ビット-MIMEtransportは1994年7月です。
2. Framework for the 8bit MIME Transport Extension
2. 8ビットのMIME輸送拡大のための枠組み
The 8bit 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 FROM command. The value associated with this parameter is a keyword indicating whether a 7bit message (in strict compliance with [1]) or a MIME message (in strict compliance with [3]) with arbitrary octet content is being sent. The syntax of the value is as follows, using the ABNF notation of [2]:
(4) キーワードBODYを使用する1つの任意のパラメタがMAIL FROMコマンドに追加されます。 [1])への徹底順守かMIMEでは、通信してください。このパラメタに関連している値が7がメッセージに噛み付いたかどうかを示すキーワードである、((任意の八重奏がある[3])への徹底順守では、内容を送ります。 [2]のABNF記法を使用して、価値の構文は以下の通りです:
body-value ::= "7BIT" / "8BITMIME"
以下をボディーで評価してください:= 「7ビット」/"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が八重奏で並べられた材料の任意の線を含むMIMEメッセージから成る満足しているボディーを提出したがっているとき(メールコマンドを使用します)、それは最初に、サーバSMTPにEHLOコマンドを発行します。 サーバ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 [1], except that a BODY parameter must appear after the address. Only one BODY parameter may be used in a single MAIL command.
八重奏で並べられた材料の任意の線を含むMIMEメッセージから成る満足しているボディーを伝えたがっているとき、拡張メールコマンドはクライアントSMTPによって発行されます。 このコマンドのための構文は[1]のメールコマンドと同じです、BODYパラメタがアドレスの後に現れなければならないのを除いて。 ただ一つのメールコマンドに1つのBODYパラメタだけを使用してもよいです。
Klensin, Freed, Rose, Stefferud & Crocker [Page 2] RFC 1652 SMTP 8bit-MIMEtransport July 1994
解放されたKlensinは上昇して、Stefferudとクロッカー[2ページ]RFC1652SMTP8ビット-MIMEtransportは1994年7月です。
The complete syntax of this extended command is defined in [5]. The esmtp-keyword is BODY and the syntax for esmtp-value is given by the syntax for body-value shown above.
この拡張コマンドの完全な構文は[5]で定義されます。 esmtp-キーワードはBODYです、そして、上に示されたボディー値のために構文でesmtp-値のための構文を与えます。
The value associated with the BODY parameter indicates whether the content body which 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 [1] ("7BIT").
BODYパラメタに関連している値は、DATAコマンドを使用することで通過される満足しているボディーが何らかの任意の八重奏で並べられた材料("8BITMIME")を含むMIMEメッセージから成るか、または完全に[1](「7ビット」)によると、コード化されるかを示します。
A server which supports the 8-bit MIME transport service extension shall preserve all bits in each octet passed using the DATA command.
8ビットのMIME輸送サービス拡大を支持するサーバはDATAコマンドを使用することで通過された各八重奏ですべてのビットを保存するものとします。
Naturally, the usual SMTP data-stuffing algorithm applies so that a content which contains the five-character sequence of
当然、データを詰める普通のSMTPアルゴリズムはしたがって、aそんなに満足していた状態で適用されます(5キャラクタシーケンスを含んでいます)。
<CR> <LF> <DOT> <CR> <LF>
<CR><LF><ドット><CR><LF>。
or a content that begins with the three-character sequence of
または、それが3キャラクタシーケンスで始まる内容
<DOT> <CR> <LF>
<ドット><CR><LF>。
does not prematurely terminate the transfer of the content. Further, it should be noted that the CR-LF pair immediately preceeding 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 may allow as few as 1000 octets on a single line). This restriction means that this extension MAY provide 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.
内容の転送は早まって、終わりません。 さらに、すぐに最終的なドットをpreceedingするCR-LF組が内容の一部であると考えられることに注意されるべきです。 満足しているボディーが八重奏で並べられた材料の任意の線を含みますが、最終的にそれぞれの線(2CR-LF組の間の八重奏の数)の長さはまだSMTPサーバー行長制限(単線における最小1000の八重奏を許容するかもしれない)を受けることがあります。 この制限は、この拡大が8BIT内容転送コード化でMIME物を移すのに必要な施設を提供するかもしれないことを意味します、それ。DOES NOTはBINARY内容転送コード化を物を移す手段に提供します。
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 which contains characters outside the US-ASCII octet range (hex 00-7F).
サーバであるなら、SMTPは8ビットのMIME輸送拡大(コード250でEHLOコマンドに応じないか、または応答でEHLOキーワード値の8BITMIMEを含めないのによる)を支持しないで、次に、クライアントSMTPは、米国-ASCII八重奏範囲(十六進法00-7F)の外にキャラクタを保管している内容を移すのをどうあっても試みてはいけません。
A client SMTP has two options in this case: first, it may implement a gateway transformation to convert the message into valid 7bit MIME, or second, or may treat this as a permanent error and handle it in
クライアントSMTPには、この場合、2つのオプションがあります: まず最初に、それは7ビットの有効なMIME、または2番目にメッセージを変換するか、永続エラーとしてこれを扱うかもしれなくて、またはそれを扱うゲートウェイ変化を実行するかもしれません。
Klensin, Freed, Rose, Stefferud & Crocker [Page 3] RFC 1652 SMTP 8bit-MIMEtransport July 1994
解放されたKlensinは上昇して、Stefferudとクロッカー[3ページ]RFC1652SMTP8ビット-MIMEtransportは1994年7月です。
the usual manner for delivery failures. The specifics of the transformation from 8bit MIME to 7bit MIME are not described by this RFC; the conversion is nevertheless constrained in the following ways:
配信障害のための普通の方法。 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)それが、情報の損失を全くもたらしてはいけません。 そしてこれがそうであることを保障するのに必要に応じてMIME輸送encodingsを使わなければならない。
(2) the resulting message must be valid 7bit 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: TCPポート25>Cにおける接続のための<待ち: サーバ>Sとの<のオープンな接続: 220 dbc.mtview.ca.us SMTPは持ち合わせのCを修理します: EHLO ymir.claremont.edu S: 250-dbc.mtview.ca.usはこんにちは、Sを言います: 250 8BITMIME C: FROM:<ned@ymir.claremont.edu に郵送してください、gt;、ボディー=8BITMIME S: 250 <ned@ymir.claremont.edu 、gt;、… 送付者と8BITMIME OK C: RCPT TO:<mrose@dbc.mtview.ca.us 、gt;、S: 250 <mrose@dbc.mtview.ca.us 、gt;、… 受取人OK C: データS: CRLF.CRLFに終わって、354は8BITMIMEメッセージを送ります。 ... C: . S: 250 OK C: 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 [1].
このRFCは安全保障問題について議論しないで、また既に電子メールの風土病の、そして、[1]の実現を完全に従わせることにおける現在でないどんな安全保障問題も提起すると信じられていません。
6. Acknowledgements
6. 承認
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
このドキュメントは他のものの考えと提案への多くの人々と反応の考えの統合を表します。 ランドル・アトキンソン、クレイグ・エバーハート、Ristoカンクネン、およびグレッグ・ボードルイは考えられた共著者であることができるのと同じくらいの考えとテキストを寄付しました。 ハラルドAlvestrand、ジム・コンクリン、マーク・クリスピン、フランク・daクルス、'Olafurグドムンソン、Per'から他の重要な提案、テキスト、または奨励が来ました。
Klensin, Freed, Rose, Stefferud & Crocker [Page 4] RFC 1652 SMTP 8bit-MIMEtransport July 1994
解放されたKlensinは上昇して、Stefferudとクロッカー[4ページ]RFC1652SMTP8ビット-MIMEtransportは1994年7月です。
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.
全体のIETF SMTP作業部会のHedeland、クリスチャンのHuitma、ニール・ケーティン、エリオットリア、ハロルド・A.ミラー、キース・ムーア、ダン・オスカルソン、ジュリアン・アニアンズ、ニール・リカート、ジョン・ワグナー、ライアンZachariassen、および貢献。 もちろん、個人のだれでも必ずここに表された考えの組み合わせに責任があるというわけではありません。 いくつかの場合本当に、特定の批評への応答が問題識別を受け入れることでしたが、元々ものからの完全に異なった解決策を含んでいるのは提案しました。
7. References
7. 参照
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.
[1] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
[2] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
[3] Borenstein、N.と解放されたN.、「マルチパーパスインターネットメールエクステンション」、RFC1521、Bellcore、Innosoft、1993年9月。
[4] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1522, University of Tennessee, September 1993.
[4] ムーア、K.、「インターネットメッセージヘッダーの非ASCIIテキストの表現」、RFC1522、テネシー大学、1993年9月。
[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.
Klensin(J.)が解放した[5]、Inc.、ネットワークマネージメントに相談するRFC1651、MCI、Innosoft、ドーヴァーが無能にするN.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPサービス拡張子」がInc.を関連づけます、シリコングラフィックス、1994年7月。
[6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, BBN, January 1986.
[6] ヤマウズラ、C.が「ルート設定とドメインシステムを郵送する」、STD14、RFC974、BBN、1月1986日
8. Chair, Editor, and Authors' Addresses
8. 議長、エディタ、および作者のアドレス
John Klensin, WG Chair MCI Data Services Division 2100 Reston Parkway, 6th floor Reston, VA 22091 USA
ジョンKlensin、WG議長MCI Data Services事業部2100レストン6階のレストン、ヴァージニア22091パークウェイ(米国)
Phone:: 1 703 715 7361 Fax: +1 703 715 7435 EMail: klensin@mci.net
以下に電話をしてください: 1、703 715、7361Fax: +1 7435年の703 715メール: klensin@mci.net
Klensin, Freed, Rose, Stefferud & Crocker [Page 5] RFC 1652 SMTP 8bit-MIMEtransport July 1994
解放されたKlensinは上昇して、Stefferudとクロッカー[5ページ]RFC1652SMTP8ビット-MIMEtransportは1994年7月です。
Ned Freed, Editor Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA
解放されたエディタのSouth Westコビーナ、Innosoftの国際Inc.1050の東ガーヴェーアベニューカリフォルニア91790ネッド(米国)
Phone:: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com
以下に電話をしてください: +1 818 919、3600Fax: +1 3614年の818 919メール: ned@innosoft.com
Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Moutain View, CA 94043-2186 USA
Inc.420Whisman法廷Moutain眺望、カリフォルニア94043-2186米国に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 415 968 1052 Fax: +1 415 968 2510 EMail: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 415 968、1052Fax: +1 2510年の415 968メール: mrose@dbc.mtview.ca.us
Einar A. Stefferud Network Management Associates, Inc. 17301 Drey Lane Huntington Beach, CA, 92647-5615 USA
Einar A.Stefferudネットワークマネージメント関連Inc.17301Drey Lane92647-5615ハンティントンビーチ(カリフォルニア)(米国)
Phone: +1 714 842 3711 Fax: +1 714 848 2091 EMail: stef@nma.com
以下に電話をしてください。 +1 714 842、3711Fax: +1 2091年の714 848メール: stef@nma.com
Dave Crocker Silicon Graphics, Inc. 2011 N. Shoreline Blvd. P.O. Box 7311 Mountain View, CA 94039 USA
デーヴ・医者シリコングラフィックス2011N.海岸線Blvd. P.O. Box7311カリフォルニア94039マウンテンビュー(米国)
Phone: +1 415 390 1804 Fax: +1 415 962 8404 EMail: dcrocker@sgi.com
以下に電話をしてください。 +1 415 390、1804Fax: +1 8404年の415 962メール: dcrocker@sgi.com
Klensin, Freed, Rose, Stefferud & Crocker [Page 6]
Klensin、フリード、ローズ、Stefferud、およびクロッカー[6ページ]
一覧
スポンサーリンク