RFC1830 日本語訳

Network Working Group                                       G. Vaudreuil
Request for Comments: 1830                        Octel Network Services
Category: Experimental                                       August 1995

コメントを求めるワーキンググループG.ボードルイの要求をネットワークでつないでください: 1830年のOctelネットワーク・サービスカテゴリ: 実験的な1995年8月

                        SMTP Service Extensions
                       for Transmission of Large
                        and Binary MIME Messages

大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

1. Abstract

1. 要約

   This memo defines two extensions to the SMTP service.  The first
   service enables a SMTP client and server to negotiate the use of an
   alternate DATA command "BDAT" for efficiently sending large MIME
   messages.  The second extension takes advantage of the BDAT command
   to permit the negotiated sending of unencoded binary data.

このメモは2つの拡大をSMTPサービスと定義します。 ファーストサービスは、SMTPクライアントとサーバが代替のDATAコマンド"BDAT"の効率的に大きいMIMEメッセージを送る使用を交渉するのを可能にします。 2番目の拡大は暗号化されていないバイナリ・データの交渉された発信を可能にするBDATコマンドを利用します。

2. Introduction

2. 序論

   The MIME extensions to the Internet message protocol provides for the
   transmission of many kinds of data which were previously unsupported
   in Internet mail.  Anticipating the need to more efficiently
   transport the new media made possible with MIME, the SMTP protocol
   has been extended to provide transport for new message types.  RFC
   1426 defines one such extension for the transmission of unencoded 8
   bit MIME messages [8BIT].  This service extension permits the
   receiver SMTP to declare support for 8 bit body parts and the sender
   to request 8 bit transmission of a particular message.

プロトコルが多くの種類の以前にインターネット・メールでサポートされなかったデータの伝達に備えるというインターネットメッセージへのMIME拡大。 より効率的にMIMEで可能にされたニューメディアを輸送する必要性を予期して、新しいメッセージタイプに輸送を提供するためにSMTPプロトコルを広げてあります。 RFC1426は8ビットの暗号化されていないMIMEメッセージ[8BIT]の伝達のためのそのような拡大の1つを定義します。 このサービス拡大は、受信機SMTPが、8ビットの身体の部分と送付者のサポートが特定のメッセージの8ビット伝送を要求すると宣言することを許可します。

   One expected result of the use of MIME is that the Internet mail
   system will be expected to carry very large mail messages.  In such
   transactions, there is a need to eliminate the requirement that the
   message be scanned for "CR LF . CR LF" sequences upon sending and
   receiving to detect the end of message.

あるものは、MIMEの使用の結果がインターネット・メールシステムが非常に大きいメール・メッセージを運ぶと予想されるということであると予想しました。 そのようなトランザクションには、メッセージの終わりを検出するために、メッセージが送受信の「CR LF CR LF」系列のためにスキャンされるという要件を排除する必要があります。

   Independent of the need to send large messages, Internet mail is
   increasingly multi-media there is a need to avoid the overhead of
   base64 and quoted-printable encoding of binary objects sent using the
   MIME message format over SMTP between hosts which support binary
   message processing.

大きいメッセージを送る必要性から独立しています、インターネット・メールはますます、そこのマルチメディアがbase64のオーバーヘッドとMIMEメッセージ・フォーマットがホストの間の2進のメッセージ処理をサポートするSMTPの上で使用させられた2進のオブジェクトの引用されて印刷可能なコード化を避ける必要性であるということです。

Vaudreuil                     Experimental                      [Page 1]

RFC 1830           Binary and Large Message Transport        August 1995

2進の、そして、メッセージ転送1995年8月に大きいボードルイ実験的な[1ページ]RFC1830

   This memo uses the mechanism defined in [ESMTP] to define two
   extensions to the SMTP service whereby a client ("sender-SMTP") may
   declare support for the message chunking transmission mode using the
   BDAT command and support for the sending of Binary messages.

このメモはクライアント(「送付者-SMTP」)がBinaryメッセージの発信のBDATコマンドとサポートを使用することでメッセージ分魂化転送方式のサポートを宣言するかもしれないSMTPサービスと2つの拡大を定義するために[ESMTP]で定義されたメカニズムを使用します。

3. Framework for the Large Message Extensions

3. 大きいメッセージ拡張子のためのフレームワーク

   The following service extension is hereby defined:

以下のサービス拡大はこれにより定義されます:

          1) The name of the data chunking service extension is
          "CHUNKING".

1) データ分魂化サービス拡張子の名前は「分魂化」です。

          2) The EHLO keyword value associated with this extension is
          "CHUNKING".

2) この拡大に関連しているEHLOキーワード価値は「分魂化」です。

          3) A new SMTP verb is defined "BDAT" as an alternative to
          the "DATA" command of [RFC821]. The BDAT verb takes two
          arguments.  The first argument indicates the length of the
          binary data packet.  The second optional argument indicates
          that the data packet is the last.

3) 新しいSMTP動詞は[RFC821]の「データ」コマンドに代わる手段として定義された"BDAT"です。 BDAT動詞は2つの議論を取ります。 最初の議論はバイナリ・データパケットの長さを示します。 2番目の任意の議論は、データ・パケットが最終であることを示します。

               bdat-cmd   ::= "BDAT" SP chunk-size
                              [ SP end-marker ] CR LF
               chunk-size ::= 1*DIGIT
               end-marker ::= "LAST"

bdat-cmd:、:= "BDAT"SP塊サイズ[SPエンドマーカー]CR LF塊サイズ:、:= 1*DIGITエンドマーカー:、:= 「最後」

   The CHUNKING service extension enables the use of the BDAT
   alternative to the DATA command.  This extension can be used for any
   message, whether 7 bit, 8BITMIME or BINARYMIME.

CHUNKINGサービス拡張子はDATAコマンドへのBDAT代替手段の使用を可能にします。 7ビット、8BITMIMEまたはBINARYMIMEであることにかかわらずどんなメッセージにもこの拡張子を使用できます。

   When a client SMTP wishes to submit (using the MAIL command) a large
   message using the CHUNKING extension, 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 CHUNKING, then the server SMTP is indicating that it supports
   the BDAT command and will accept the sending of messages in chunks.

クライアントSMTPがCHUNKING拡張子を使用することで大きいメッセージを提出したがっているとき(メールコマンドを使用します)、それは最初に、サーバSMTPにEHLOコマンドを発行します。 サーバSMTPがコード250でEHLOコマンドに応じて、応答がEHLOキーワード値のCHUNKINGを含んでいると、サーバSMTPはBDATがコマンドであるとサポートするのを示していて、塊における、メッセージの発信を受け入れるでしょう。

   After all MAIL FROM and RCPT TO responses are collected and
   processed, the message is sent using a series of BDAT commands.  The
   BDAT command takes one argument, the exact length of the data segment
   in octets.  The message data is sent immediately after the BDAT
   command.  Once the receiver-SMTP receives the specified number of
   octets, it will return a 250 reply code.

すべてのMAIL FROMとRCPT TO応答を集めて、処理した後に、メッセージに一連のBDATコマンドを使用させます。 BDATコマンドは1つの議論、八重奏における、データ・セグメントの正確な長さを取ります。 BDATコマンド直後メッセージデータを送ります。 受信機-SMTPがいったん八重奏の指定された数を受けると、それは250回答コードを返すでしょう。

   The LAST parameter on the BDAT command indicates that this is the
   last chunk of message data to be sent.  Any BDAT command sent after
   the BDAT LAST is illegal and must be replied to with a 503 "Bad

BDATコマンドに関するLASTパラメタは、これがメッセージデータの最後の送られるべき塊であることを示します。 どんなBDATコマンドもBDAT LASTが不法になった後に送られて、503が「悪い」状態で答えなければなりません。

Vaudreuil                     Experimental                      [Page 2]

RFC 1830           Binary and Large Message Transport        August 1995

2進の、そして、メッセージ転送1995年8月に大きいボードルイ実験的な[2ページ]RFC1830

   sequence of commands" reply code. The state resulting from this error
   is indeterminate.  A RSET command must be sent to clear the
   transaction before continuing.

「コマンドの系列」回答コード。 この誤りから生じる状態は不確定です。 続く前にトランザクションをクリアするためにRSETコマンドを送らなければなりません。

   A 250 response should be sent to each BDAT data block.  If a 5XX code
   is sent in response to a BDAT chunk the message should be considered
   failed and, the sender SMTP must not send any additional BDAT
   segments.  If using the ESMTP pipelining extensions [PIPE], the
   sender SMTP must complete the sending of the current segment and not
   send any more BDATs.  When streaming, the receiver SMTP must accept
   and discard additional BDAT chunks after the failed BDAT.  After
   receiving a 5XX error in response to a BDAT command, the resulting
   state is indeterminate.  A RSET command must be issued to clear the
   transaction before additional commands may be sent.

それぞれのBDATデータ・ブロックに250応答を送るべきです。 BDAT塊に対応して5XXコードを送るなら、失敗されているとメッセージを考えるべきです、そして、送付者SMTPはどんな追加BDATセグメントも送ってはいけません。 ESMTPパイプライン処理拡張子[PIPE]を使用するなら、送付者SMTPは現在のセグメントの発信を完成して、それ以上のBDATsを送ってはいけません。 流れるとき、受信機SMTPは失敗したBDATの後に追加BDAT塊を受け入れて、捨てなければなりません。 BDATコマンドに対応して5XX誤りを受けた後に、結果として起こる状態は不確定です。 追加コマンドを送るかもしれない前にトランザクションをクリアするためにRSETコマンドを発行しなければなりません。

      Note that an error on the receiver SMTP such as disk full or
      imminent shutdown can only be reported after the BDAT segment has
      been sent.  It is therefore important to choose a reasonable chunk
      size given the expected end to end bandwidth.

BDATセグメントを送った後にディスクの完全であるか差し迫っている閉鎖などの受信機SMTPにおける誤りを報告できるだけであることに注意してください。 したがって、帯域幅を終わらせる予想された終わりを考えて、妥当な塊サイズを選ぶのは重要です。

   The RSET command when issued during after the first BDAT and before
   the BDAT LAST clears all segments sent during that transaction and
   resets the session.

最初のBDATの後とBDAT LASTがそのトランザクションの間に送られたすべてのセグメントをクリアして、セッションをリセットする前にRSETは発行されたいつを命令するか。

   DATA and BDAT commands cannot be used in the same transaction.  If a
   DATA statement is issued after a BDAT for the current transaction, a
   503 "Bad sequence of commands" must be issued.  The state resulting
   from this error is indeterminate.  A RSET command must be sent to
   clear the transaction before continuing.  There is no prohibition on
   using DATA and BDAT in the same session, so long as they are not
   mixed in the same transaction.

同じトランザクションにDATAとBDATコマンドを使用できません。 BDATの後に経常取引のためにDATA声明を発行するなら、「コマンドの悪い系列」を発行しなければならない503です。 この誤りから生じる状態は不確定です。 続く前にトランザクションをクリアするためにRSETコマンドを送らなければなりません。 同じセッションのときにDATAとBDATを使用するとき、禁止が全くありません、それらが同じトランザクションで混ぜられない限り。

   The local storage size of a message may not accurately reflect the
   actual size of the message sent due to local storage conventions.  In
   particular, text messages sent with the BDAT command must be sent in
   the canonical MIME format with lines delimited with a <CR><LF>.  It
   may not be possible to convert the entire message to the canonical
   format at once. Chunking provides a mechanism to convert the message
   to canonical form, accurately count the bytes, and send the message a
   single chunk at a time.

メッセージの地方のストレージサイズは正確に地方のストレージコンベンションのため送られたメッセージの実サイズを反映しないかもしれません。 系列が<CR><LF>で区切られている状態で、特に、正準なMIME形式でBDATコマンドと共に送られたテキスト・メッセージを送らなければなりません。 すぐに全体のメッセージを正準な形式に変換するのは可能でないかもしれません。 分魂化は、一度にメッセージを標準形に変換して、正確にバイトを数えて、ただ一つの塊をメッセージに送るためにメカニズムを提供します。

      Note that correct byte counting is essential.  If too many bytes
      are indicated by the sender SMTP, the receiver SMTP will continue
      to wait for the remainder of the data or will read the subsequent
      command as additional message data.  In the case where a portion
      of the previous command was read as data, the parser will return a
      syntax error when the incomplete command is read.

正しいバイト勘定が不可欠であることに注意してください。 あまりに多くのバイトが送付者SMTPによって示されると、受信機SMTPは、データの残りを待ち続けるか、またはその後のコマンドを追加メッセージデータと読むでしょう。 前のコマンドの部分がデータと読まれた場合では、不完全なコマンドが読まれるとき、パーサは構文エラーを返すでしょう。

Vaudreuil                     Experimental                      [Page 3]

RFC 1830           Binary and Large Message Transport        August 1995

2進の、そして、メッセージ転送1995年8月に大きいボードルイ実験的な[3ページ]RFC1830

      If too few bytes are indicated by the sender SMTP, the receiver
      SMTP will interpret the remainder of the message data as invalid
      commands.  Note that the remainder of the message data may be
      binary and as such lexigraphical parsers must be prepared to
      receive, process, and reject lines of arbitrary octets.

あまりに数バイトしか送付者SMTPによって示されないと、受信機SMTPは無効のコマンドとしてメッセージデータの残りを解釈するでしょう。 メッセージデータの残りが2進であるかもしれないことに注意してください、そして、受信するようにそのようなlexigraphicalパーサを準備しなければならないとき、処理してください、そして、任意の八重奏の系列を拒絶してください。

4. Framework for the Binary Service Extension

4. 2進のサービス拡大のためのフレームワーク

   The following service extension is hereby defined:

以下のサービス拡大はこれにより定義されます:

      1) The name of the binary service extension is "BINARYMIME".

1) 2進のサービス拡大の名前は"BINARYMIME"です。

      2) The EHLO keyword value associated with this extension is
         "BINARYMIME".

2) この拡大に関連しているEHLOキーワード価値は"BINARYMIME"です。

      3) The BINARYMIME service extension can only be used with
         the "CHUNKING" service extension.

3) 「分魂化」サービス拡大と共にBINARYMIMEサービス拡張子を使用できるだけです。

      4) No parameter is used with the BINARYMIME keyword.

4) パラメタは全くBINARYMIMEキーワードと共に使用されません。

      5) One additional parameter to the BODY keyword defined
         [8BIT] for the MAIL FROM command is defined, "BINARYMIME".
         The value "BINARYMIME" associated with this parameter
         indicates that this message is a Binary MIME message (in
         strict compliance with [MIME]) with arbitrary octet content
         being sent. The revised syntax of the value is as follows,
         using the ABNF notation of [RFC822]:

5) BODYキーワードへの1つの追加パラメタがFROMが定義されると命令するメール、"BINARYMIME"のために[8BIT]を定義しました。 このパラメタに関連している値の"BINARYMIME"は、このメッセージが2進のMIMEメッセージであることを任意の八重奏内容を送って示します([MIME]への徹底順守で)。 [RFC822]のABNF記法を使用して、価値の改訂された構文は以下の通りです:

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

以下をボディーで評価してください:= 「7ビット」/"8BITMIME"/"BINARYMIME"

      6) No new verbs are defined for the BINARYMIME extension.

6) どんな新しい動詞もBINARYMIME拡張子のために定義されません。

   A sender SMTP may request that a binary MIME message be sent without
   transport encoding by sending a BINARYMIME parameter with the MAIL
   FROM command.  When the receiver SMTP accepts a MAIL FROM command
   with the BINARYMIME body type requested, it agrees to preserve all
   bits in each octet passed using the BDAT command.

送付者SMTPは、2進のMIMEメッセージがMAIL FROMコマンドと共にBINARYMIMEパラメタを送るのによる輸送コード化なしで送られるよう要求するかもしれません。 BINARYMIMEボディータイプが要求されている状態で受信機SMTPがMAIL FROMコマンドを受け入れるとき、それは、BDATコマンドを使用することで通過された各八重奏ですべてのビットを保存するのに同意します。

   BINARYMIME cannot be used with the DATA command.  If a DATA command
   is issued after a MAIL FROM command containing the body-value of
   "BINARYMIME", a 501 response should be sent.  The resulting state
   from this error condition is indeterminate and the transaction should
   be reset with the RSET command.

DATAコマンドと共にBINARYMIMEを使用できません。 "BINARYMIME"のボディー値を含むメールFROMコマンドの後にDATAコマンドを発行するなら、501応答を送るべきです。 このエラー条件からの結果として起こる状態は不確定です、そして、トランザクションはRSETコマンドでリセットされるべきです。

      It is important to note that when using BINARYMIME, it is
      especially important to ensure that the MIME message itself is
      properly formed.  In particular, it is essential that text be
      canonically encoded with each line properly terminated with <CR>

BINARYMIMEを使用するとき、MIMEメッセージ自体が適切に形成されるのを保証するのが特に重要であることに注意するのは重要です。 各系列が<CR>で適切に終えられている状態でテキストが正準にコード化されるのは、特に、不可欠です。

Vaudreuil                     Experimental                      [Page 4]

RFC 1830           Binary and Large Message Transport        August 1995

2進の、そして、メッセージ転送1995年8月に大きいボードルイ実験的な[4ページ]RFC1830

      <LF>.  Any transformation of text into non-canonical MIME to
      observe local storage conventions must be reversed before sending
      as BINARYMIME.  The usual line-oriented shortcuts will break if
      used with BINARYMIME.

<LF>。 BINARYMIMEとして発信する前に、地方のストレージコンベンションを観測する正典外のMIMEへのテキストのどんな変換も逆にしなければなりません。 BINARYMIMEと共に使用されると、普通の系列指向の近道は壊れるでしょう。

   The syntax of the extended MAIL command is identical to the MAIL
   command in [RFC821], except that a BODY parameter must appear after
   the address.  The complete syntax of this extended command is defined
   in [ESMTP]. The ESMTP-keyword is BODY and the syntax for ESMTP-value
   is given by the syntax for body-value in [ESMTP].

拡張メールコマンドの構文は[RFC821]のメールコマンドと同じです、BODYパラメタがアドレスの後に現れなければならないのを除いて。 この拡張コマンドの完全な構文は[ESMTP]で定義されます。 ESMTP-キーワードはBODYです、そして、[ESMTP]のボディー値のために構文でESMTP-値のための構文を与えます。

   If a receiver SMTP does not support the BINARYMIME message format
   (either by not responding with code 250 to the EHLO command, or by
   rejecting the BINARYMIME parameter to the MAIL FROM command, then the
   client SMTP must not, under any circumstances, send binary data using
   the DATA or BDAT commands.

SMTPは、受信機であるならBINARYMIMEがメッセージ・フォーマットであるとサポートしません。(次に、コード250でEHLOコマンドに応じないか、またはMAIL FROMコマンドにBINARYMIMEパラメタを拒絶することによって、クライアントSMTPはDATAかBDATコマンドを使用することでどうあってもバイナリ・データを送ってはいけません。

   If the receiver-SMTP does not support BINARYMIME and the message
   content is a MIME object with a binary encoding, a client SMTP has
   two options in this case: first, it may implement a gateway
   transformation to convert the message into valid 7bit encoded MIME,
   or second, it may treat this as a permanent error and handle it in
   the usual manner for delivery failures.  The specifics of the
   transformation from Binary MIME to 7bit MIME are not described by
   this RFC; the conversion is nevertheless constrained in the following
   ways:

受信機-SMTPがBINARYMIMEをサポートしないで、メッセージ内容がバイナリーがコード化されているMIMEオブジェクトであるなら、クライアントSMTPには、この場合、2つのオプションがあります: まず最初に、有効な7ビットコード化されたMIMEにメッセージを変換するためにゲートウェイ変換を実装するかもしれないか、それは、2番目に、永続エラーとしてこれを扱って、常法で配信障害によってそれを扱うかもしれません。 Binary MIMEから7ビットのMIMEまでの変換の詳細はこのRFCによって説明されません。 それにもかかわらず、変換は以下の方法で抑制されます:

     o  The conversion must cause no loss of information; MIME
        transport encodings must be employed as needed to insure this
        is the case.

o 変換が、情報の損失を全くもたらしてはいけません。 これがそうであることを保障するのに必要に応じてMIME輸送encodingsを使わなければなりません。

     o  The resulting message must be valid 7bit MIME.

o 結果として起こるメッセージは7ビットの有効なMIMEであるに違いありません。

   As of present there are no mechanisms for converting a binary MIME
   object into a 8 bit-MIME object.  Such a transformation will require
   the specification of a new MIME content-transfer-encoding, the
   standardization of which is discouraged by [MIME].

プレゼント現在、8ビットMIMEオブジェクトに2進のMIMEオブジェクトを変換するためのメカニズムが全くありません。 そのような変換は新しいMIME満足している転送コード化の仕様を必要とするでしょう。その標準化は[MIME]でお勧めできないです。

Vaudreuil                     Experimental                      [Page 5]

RFC 1830           Binary and Large Message Transport        August 1995

2進の、そして、メッセージ転送1995年8月に大きいボードルイ実験的な[5ページ]RFC1830

5. Examples

5. 例

5.1 Simple Chunking

5.1 簡単な分魂化

   The following simple dialogue illustrates the use of the large
   message extension to send a short psudo-RFC822 message to one
   recipient using the CHUNKING extension:

以下の簡単な対話はCHUNKING拡張子を使用することで短いpsudo-RFC822メッセージを1人の受取人に送るために大きいメッセージ拡張子の使用を例証します:

          R: <wait for connection on TCP port 25>
          S: <open connection to server>
          R: 220 cnri.reston.va.us SMTP service ready
          S: EHLO ymir.claremont.edu
          R: 250-cnri.reston.va.us says hello
          R: 250 CHUNKING
          S: MAIL FROM:<Sam@Random.com>
          R: 250 <Sam@Random.com>... Sender ok
          S: RCPT TO:<Susan@Random.com>
          R: 250 <Susan@random.com>... Recipient ok
          S: BDAT 69 LAST
          S: To: Susan@random.com<CR><LF>
          S: From: Sam@random.com<CR><LF>
          S: Subject: This is a bodyless test message<CR><LF>
          R: 250 Message OK, 69 octets received
          S: QUIT
          R: 221 Goodbye

R: TCPポート25>Sにおける接続のための<待ち: サーバ>Rとの<のオープンな接続: 220 cnri.reston.va.us SMTPは持ち合わせのSを修理します: EHLO ymir.claremont.edu R: 250-cnri.reston.va.usはこんにちは、Rを言います: 250 分魂化S: FROM:<Sam@Random.com に郵送してください、gt;、R: 250 <Sam@Random.com 、gt;、… 送付者OK S: RCPT TO:<Susan@Random.com 、gt;、R: 250 <Susan@random.com 、gt;、… 受取人OK S: BDAT69はSを持続します: To: Susan@random.com 、lt;、CR><LF>S: From: Sam@random.com 、lt;、CR><LF>S: Subject: これはbodylessテストメッセージ<CR><LF>Rです: 250 Message OK、69の八重奏がSを受けました: Rをやめてください: 221さよなら

5.2 Pipelining Binarymime

5.2 パイプライン処理Binarymime

   The following dialogue illustrates the use of the large message
   extension to send a BINARYMIME object to two recipients using the
   CHUNKING and PIPELINING extensions:

以下の対話はCHUNKINGとPIPELINING拡張子を使用することでBINARYMIMEオブジェクトを2人の受取人に送るために大きいメッセージ拡張子の使用を例証します:

          R: <wait for connection on TCP port 25>
          S: <open connection to server>
          R: 220 cnri.reston.va.us SMTP service ready
          S: EHLO ymir.claremont.edu
          R: 250-cnri.reston.va.us says hello
          R: 250-PIPELINING
          R: 250-BINARYMIME
          R: 250 CHUNKING
          S: MAIL FROM:<ned@ymir.claremont.edu> BODY=BINARYMIME
          S: RCPT TO:<gvaudre@cnri.reston.va.us>
          S: RCPT TO:<jstewart@cnri.reston.va.us>
          R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
          R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
          R: 250 <jstewart@cnri.reston.va.us>... Recipient ok
          S: BDAT 100000

R: TCPポート25>Sにおける接続のための<待ち: サーバ>Rとの<のオープンな接続: 220 cnri.reston.va.us SMTPは持ち合わせのSを修理します: EHLO ymir.claremont.edu R: 250-cnri.reston.va.usはこんにちは、Rを言います: 250パイプライン処理R: 250-BINARYMIME R: 250 分魂化S: FROM:<ned@ymir.claremont.edu に郵送してください、gt;、ボディー=BINARYMIME S: RCPT TO:<gvaudre@cnri.reston.va.us 、gt;、S: RCPT TO:<jstewart@cnri.reston.va.us 、gt;、R: 250 <ned@ymir.claremont.edu 、gt;、… 送付者とBINARYMIME OK R: 250 <gvaudre@cnri.reston.va.us 、gt;、… 受取人OK R: 250 <jstewart@cnri.reston.va.us 、gt;、… 受取人OK S: BDAT100000

Vaudreuil                     Experimental                      [Page 6]

RFC 1830           Binary and Large Message Transport        August 1995

2進の、そして、メッセージ転送1995年8月に大きいボードルイ実験的な[6ページ]RFC1830

          S: (First 10000 octets of canonical MIME message data)
          S: BDAT 324 LAST
          S: (Remaining 324 octets of canonical MIME message data)
          R: 250 100000 bytes received
          R: 250 Message OK, 100324 octets received
          S: QUIT
          R: 221 Goodbye

S: (最初に、正準なMIMEメッセージデータの10000の八重奏) S: BDAT324はSを持続します: (正準なMIMEメッセージデータの324の八重奏のままで残っています) R: 250 100000バイトはRを受けました: 250 Message OK、100324の八重奏がSを受けました: Rをやめてください: 221さよなら

6. Security Considerations

6. セキュリティ問題

   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 [RFC821], or otherwise
   made possible by [MIME].

このRFCは安全保障問題について議論しないで、また既に電子メールの風土病の、そして、[RFC821]の実装を完全に従わせることにおいて現在でないか、または別の方法で[MIME]によって可能にされなかった少しの安全保障問題も提起すると信じられていません。

7. Acknowledgments

7. 承認

   This document is the result of numerous discussions in the IETF SMTP
   Extensions Working Group and in particular due to the continued
   advocacy of "chunking" by Neil Katin.

このドキュメントはIETF SMTP Extensions作業部会と特にニール・ケーティンが「分魂化」の継続的な支持のため頻繁な議論の結果です。

8. References

8. 参照

     [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
        821, USC/Information Sciences Institute, August 1982.

[RFC821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。

     [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
        Text Messages", STD 11, RFC 822, UDEL, August 1982.

[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。

     [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
        Extensions", RFC 1521, Bellcore, Innosoft, June 1992.

[まねます] Borenstein、N.と解放されたN.、「マルチパーパスインターネットメールエクステンション」、RFC1521、Bellcore、Innosoft、1992年6月。

     [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
        Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC
        1425, United Nations University, Innosoft International,
        Inc., Dover Beach Consulting, Inc., Network Management
        Associates, Inc., The Branch Office, February 1993.

[ESMTP]Klensin、J.、WG議長、解放されています、N.とエディタとローズとM.とStefferud、E.とD.クロッカー、「SMTPサービス拡張子」RFC1425、国連大学、Innosoftの国際Inc.、ドーヴァービーチコンサルティングInc.、ネットワークマネージメントはInc.を関連づけます、支店、1993年2月。

     [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
        Stefferud, E., and D. Crocker, "SMTP Service Extension for
        8bit-MIMEtransport" RFC 1426, United Nations University,
        Innosoft International, Inc., Dover Beach Consulting, Inc.,
        Network Management Associates, Inc., The Branch Office,
        February 1993.

[8ビット] WG議長、解放されたKlensin、J.、N.、エディタ、ローズ、M.、Stefferud、E.、およびD.クロッカー、「8ビット-MIMEtransportのためのSMTPサービス拡張子」RFC1426、国連大学、Innosoftの国際Inc.、ドーヴァービーチコンサルティングInc.、ネットワークマネージメントはInc.を関連づけます、支店、1993年2月。

     [PIPE] Freed, N., "SMTP Service Extensions for Command
        Pipelining", Innosoft International, Work in Progress.

[運びます] 解放されていて、N.、Innosoftインターナショナルな「コマンド連続送信のためのSMTPサービス拡張子」が進行中で働いています。

Vaudreuil                     Experimental                      [Page 7]

RFC 1830           Binary and Large Message Transport        August 1995

2進の、そして、メッセージ転送1995年8月に大きいボードルイ実験的な[7ページ]RFC1830

9. Author's Address

9. 作者のアドレス

   Gregory M. Vaudreuil
   Octel Network Services
   17060 Dallas Parkway
   Suite 214
   Dallas, TX 75248-1905

ダラス、グレゴリーM.ボードルイのOctelネットワーク・サービス17060ダラス公園道路Suite214テキサス75248-1905

   Voice/Fax: 214-733-2722
   EMail: Greg.Vaudreuil@Octel.com

声/Fax: 214-733-2722 メールしてください: Greg.Vaudreuil@Octel.com

Vaudreuil                     Experimental                      [Page 8]

ボードルイ実験的です。[8ページ]