Network Working Group G. Vaudreuil
Request for Comments: 3030 Lucent Technologies
Obsolete: 1830 December 2000
Category: Standards Track
SMTP Service Extensions
for Transmission of Large
and Binary MIME Messages
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called "BDAT", for efficiently sending large MIME (Multipurpose Internet Mail Extensions) messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of MIME messages that employ the binary transfer encoding. This document is intended to update and obsolete RFC 1830.
このメモは、SMTP（簡易メール転送プロトコル）サービスに2つの拡張を定義します。最初の拡張は、効率的に大規模なMIME（多目的インターネットメール拡張）メッセージを送信するために、「BDAT」と呼ばれるDATAコマンドの代替の使用を交渉するSMTPクライアントとサーバを可能にします。第二の延長部は、ネゴシエートされたバイナリ転送エンコードを使用MIMEメッセージの送信を可能にするためにBDATコマンドを利用します。この文書は、RFC 1830を更新し、廃止されたことを意図しています。
Working Group Summary
ワーキンググループの概要
This protocol is not the product of an IETF working group, however the specification resulted from discussions within the ESMTP working group. The resulting protocol documented in RFC 1830 was classified as experimental at that time due to questions about the robustness of the Binary Content-Transfer-Encoding deployed in then existent MIME implementations. As MIME has matured and other uses of the Binary Content-Transfer-Encoding have been deployed, these concerns have been allayed. With this document, Binary ESMTP is expected to become standards-track.
このプロトコルはIETFワーキンググループの製品ではありません、しかし仕様がESMTPワーキンググループ内での議論から生じました。 RFC 1830で文書化結果のプロトコルが原因その後、既存のMIME実装に配備バイナリコンテンツ転送エンコードの堅牢性についての質問にその時点での実験として分類されました。 MIMEが成熟しているとバイナリコンテンツ転送エンコードの他の用途が展開されているように、これらの懸念が和らげられています。この文書では、バイナリESMTPは標準トラックとなることが期待されます。
Document Conventions
ドキュメントの表記規則
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Table of Contents
目次
1. Overview ................................................... 2
2. Framework for the Large Message Extensions ................. 3
3. Framework for the Binary Service Extension ................. 5
4. Examples ................................................... 8
4.1 Simple Chunking .......................................... 8
4.2 Pipelining BINARYMIME .................................... 8
5. Security Considerations .................................... 9
6. References ................................................. 9
7. Author's Address ........................................... 10
8. Appendix A - Changes from RFC 1830 ......................... 11
9. Full Copyright Statement ................................... 12
The MIME extensions to the Internet message format provides for the transmission of many kinds of data that were previously unsupported in Internet mail. Anticipating the need to transport the new media more efficiently, the SMTP protocol has been extended to provide transport for new message types. RFC 1652 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拡張は、インターネットメールで以前にサポートされていないたデータの多くの種類の伝送を提供します。より効率的に新しいメディアを輸送する必要性を先取りし、SMTPプロトコルは、新しいメッセージタイプのための輸送を提供するために拡張されました。 RFC 1652は、[8BIT]エンコードされていない8ビットMIMEメッセージの送信のための1つのそのような拡張を定義します。このサービス拡張は、8ビットの本体部と、特定のメッセージの8ビットの送信を要求する送信者のサポートを宣言する受信SMTPを可能にします。
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 performance-based desire 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 multimedia. 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 that support binary message processing.
大きなメッセージを送信する必要の独立した、インターネットメールはますますマルチメディアです。バイナリメッセージ処理をサポートするホストとの間のSMTP上MIMEメッセージフォーマットを使用して送信されたバイナリオブジェクトのBASE64及び引用印刷可能な符号化のオーバーヘッドを回避する必要があります。
This memo uses the mechanism defined in [ESMTP] to define two extensions to the SMTP service whereby an SMTP server ("receiver-SMTP") may declare support for the message chunking transmission mode and support for the reception of Binary messages, which the SMTP client ("sender-SMTP") is then free to use.
SMTPサーバ（「受信側SMTP」）はバイナリメッセージの受信、SMTPの送信モードおよびサポートをチャンクメッセージのサポートを宣言することができることにより、このメモは、SMTPサービスへの2つの拡張を定義する[ESMTP]で定義されたメカニズムを使用しクライアント（「送信側SMTP」）を自由に使用できます。
The following service extension is hereby defined:
以下のサービス拡張は、ここに定義されています。
1) The name of the data chunking service extension is "CHUNKING".
1）データチャンキングサービス拡張の名前は「CHUNKING」です。
2) The EHLO keyword value associated with this extension is "CHUNKING".
2）この拡張に関連付けられているEHLOキーワード値は「CHUNKING」です。
3) A new SMTP verb, BDAT, is defined as an alternative to the "DATA" command of [RFC821]. The BDAT verb takes two arguments. The first argument indicates the length, in octets, of the binary data chunk. The second optional argument indicates that the data chunk is the last.
3）新しいSMTP動詞、BDATは、[RFC821]の「DATA」コマンドに代わるものとして定義されます。 BDAT動詞は2つの引数を取ります。最初の引数は、バイナリデータチャンクのオクテットの長さを、示しています。オプションの2番目の引数は、データチャンクが最後であることを示しています。
bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
chunk-size ::= 1*DIGIT
end-marker ::= "LAST"
4) This extension may be used for SMTP message submission. [Submit]
4）この拡張は、SMTPメッセージの送信のために使用することができます。 [提出する]
5) Servers that offer the BDAT extension MUST continue to support the regular SMTP DATA command. Clients are free to use DATA to transfer appropriately encoded to servers that support the CHUNKING extension if they wish to do so.
5）BDAT拡張を提供するサーバーは、通常のSMTP DATAコマンドをサポートし続けなければなりません。クライアントは、彼らがそうしたい場合CHUNKING拡張をサポートするサーバーに適切にエンコードされた転送するデータを自由に使用できます。
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 sender-SMTP wishes to send (using the MAIL command) a large message using the CHUNKING extension, it first issues the EHLO command to the receiver-SMTP. If the receiver-SMTP responds with code 250 to the EHLO command and the response includes the EHLO keyword value CHUNKING, then the receiver-SMTP is indicating that it supports the BDAT command and will accept the sending of messages in chunks.
送信側SMTPは、（MAILコマンドを使用して）CHUNKING拡張を使用して大きなメッセージを送信することを望む場合には、第1の受信機 - SMTPにEHLOコマンドを発行します。受信側SMTPは、EHLOコマンドにコード250で応答し、応答がEHLOキーワード値CHUNKINGを含み、受信機-SMTPは、BDATコマンドをサポートし、チャンク内のメッセージの送信を受け入れることを示している場合。
After all MAIL and RCPT responses are collected and processed, the message is sent using a series of BDAT commands. The BDAT command takes one required argument, the exact length of the data segment in octets. The message data is sent immediately after the trailing <CR> <LF> of the BDAT command line. Once the receiver-SMTP receives the specified number of octets, it will return a 250 reply code.
すべてのMAILとRCPT応答が収集され、処理された後、メッセージは、BDATの一連のコマンドを使用して送信されます。 BDATコマンドは、1つの必須引数、オクテットのデータセグメントの正確な長さをとります。メッセージデータは、BDATコマンドラインの末尾<CR> <LF>の直後に送信されます。受信側SMTPは、オクテットの指定された数を受信すると、それは250応答コードが返されます。
The optional LAST parameter on the BDAT command indicates that this is the last chunk of message data to be sent. The last BDAT command MAY have a byte-count of zero indicating there is no additional data to be sent. Any BDAT command sent after the BDAT LAST is illegal and MUST be replied to with a 503 "Bad 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.
BDATコマンドのオプションの最後のパラメータは、これは、メッセージデータの最後のチャンクが送信されることを示しています。最後BDATコマンドを送信する追加データがありません示すゼロのバイトカウントを持っているかもしれません。 BDAT LAST後に送信されたBDATコマンドは違法であり、応答コード503「のコマンドの悪いシーケンス」とに答えなければなりません。このエラーから生じる状態は不確定です。 RSETコマンドは、続行する前に、トランザクションをクリアするために送らなければなりません。
A 250 response MUST be sent to each successful BDAT data block within a mail transaction. If a failure occurs after a BDAT command is received, the receiver-SMTP MUST accept and discard the associated message data before sending the appropriate 5XX or 4XX code. If a 5XX or 4XX code is received by the sender-SMTP in response to a BDAT chunk, the transaction should be considered failed and the sender-SMTP MUST NOT send any additional BDAT segments. If the receiver-SMTP has declared support for command pipelining [PIPE], the receiver SMTP MUST be prepared to accept and discard additional BDAT chunks already in the pipeline after the failed BDAT.
250応答は、メールトランザクション内の各成功したBDATデータブロックに送らなければなりません。 BDATコマンドを受信した後に障害が発生した場合、受信側SMTPは、受け入れ、適切な5XXまたは4XXコードを送信する前に、関連するメッセージデータを破棄しなければなりません。 5XXまたは4XXコードがBDATチャンクに応じて、送信側SMTPによって受信された場合、トランザクションは失敗したと考えるべきであると送信側SMTPは、追加のBDATセグメントを送ってはいけません。受信側SMTPは、コマンドパイプライン[PIPE]のサポートを宣言した場合、受信側SMTPは、失敗したBDAT後のパイプラインにすでに追加BDATチャンクを受け入れ、廃棄するために準備しなければなりません。
Note: An error on the receiver-SMTP such as disk full or imminent shutdown can only be reported after the BDAT segment has been received. It is therefore important to choose a reasonable chunk size given the expected end-to-end bandwidth.
注：BDATセグメントが受信された後、ディスク全体または差し迫ったシャットダウンなどの受信側SMTP上のエラーは、報告することができます。予想されるエンドツーエンドの帯域幅が与えられた合理的なチャンクサイズを選択することが重要です。
Note: Because the receiver-SMTP does not acknowledge the BDAT command before the message data is sent, it is important to send the BDAT only to systems that have declared their capability to accept BDAT commands. Illegally sending a BDAT command and associated message data to a non-CHUNKING capable system will result in the receiver-SMTP parsing the associated message data as if it were a potentially very long, ESMTP command line containing binary data.
注意：メッセージデータが送信される前に、受信側SMTPは、BDATコマンドを認識しないので、それだけでBDATコマンドを受け入れるように自分の能力を宣言しているシステムにBDATを送信することが重要です。不正がバイナリデータを含む潜在的に非常に長い、ESMTPコマンドラインであるかのように関連付けられたメッセージ・データを解析する受信機、SMTPをもたらす非CHUNKING可能なシステムにBDATコマンドと関連付けられたメッセージデータを送信します。
The resulting state from a failed BDAT command is indeterminate. A RSET command MUST be issued to clear the transaction before additional commands may be sent. The RSET command, when issued after the first BDAT and before the BDAT LAST, clears all segments sent during that transaction and resets the session.
失敗したBDATコマンドからの結果の状態は不定です。 RSETコマンドは、追加のコマンドが送信される前に、トランザクションをクリアするために発行する必要があります。最初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コマンドは、同じトランザクションで使用することはできません。 DATA文は現在のトランザクションのためにBDAT後に発行された場合、503「のコマンドの悪いシーケンスは」発行する必要があります。このエラーから生じる状態は不確定です。 RSETコマンドは、続行する前に、トランザクションをクリアするために送らなければなりません。限り、彼らは同じトランザクション内で混合されていないと、同じセッション内のデータと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.
メッセージのローカルストレージのサイズを正確によるローカルストレージ規則に送信されたメッセージの実際のサイズを反映しないかもしれません。具体的には、BDATコマンドで送信されたテキストメッセージは、<CR> <LF>で区切ら線で正規MIME形式で送信されなければなりません。一度に標準形式にメッセージ全体を変換することが可能ではないかもしれません。 CHUNKINGを正確に、標準形式にメッセージを変換するバイトをカウントし、一度にメッセージを単一のチャンクを送信するためのメカニズムを提供します。
Note: Correct byte counting is essential. If the sender-SMTP indicates a chunk-size larger than the actual chunk-size, the receiver-SMTP will continue to wait for the remainder of the data or when using streaming, 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はデータの残りを待つ続けるまたはストリーミングを使用する場合、追加のメッセージデータとして後続のコマンドを読み取ります。不完全なコマンドが読み込まれるときに、前のコマンドの一部はデータとして読み取った場合、パーサは、構文エラーが返されます。
If the sender-SMTP indicates a chunk-size smaller than the actual chunk-size, 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 lexicographical parsers MUST be prepared to receive, process, and reject lines of arbitrary octets.
送信側SMTPは、実際のチャンクサイズよりチャンクサイズより小さく示している場合、受信側SMTPは無効コマンドなどのメッセージデータの残りの部分を解釈します。メッセージデータの残りの部分は、バイナリおよびそのような辞書式パーサーは、処理を受けるために調製し、任意のオクテットの行を拒絶しなければならないようにしてもよいことに留意されたいです。
The following service extension is hereby defined:
以下のサービス拡張は、ここに定義されています。
1) The name of the binary service extension is "BINARYMIME".
1）バイナリサービス拡張の名前は「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サービス拡張は、「CHUNKING」サービス拡張と共に使用することができます。
4) No parameter is used with the BINARYMIME keyword.
4）無パラメータがBINARYMIMEキーワードで使用されません。
5) [8BIT] defines the BODY parameter for the MAIL command. This extension defines an additional value for the BODY parameter, "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）[8BIT] MAILコマンドの身体パラメータを定義します。この拡張は、BODYパラメータ、「BINARYMIME」のための追加の値を定義します。このパラメータに関連付けられた値「BINARYMIME」は、このメッセージが送信されている任意のオクテット含有量（[MIME]に厳密に準拠した）バイナリMIMEメッセージであることを示しています。 [RFC822]のABNF表記法を使用して、次のように値の改訂版構文は次のとおりです。
body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
6) No new verbs are defined for the BINARYMIME extension.
6）いいえ新しい動詞がBINARYMIME拡張のために定義されていません。
7) This extension may be used for SMTP message submission. [Submit]
7）この拡張は、SMTPメッセージの送信のために使用することができます。 [提出する]
8) The maximum length of a MAIL FROM command line is increased by 16 characters by the possible addition of the BODY=BINARYMIME keyword and value;.
8）コマンドラインからMAILの最大長は、BODY = BINARYMIMEキーワードと値の可能な添加により16文字だけ増加さ;.
A sender-SMTP may request that a binary MIME message be sent without transport encoding by sending a BODY parameter with a value of "BINARYMIME" with the MAIL command. When the receiver-SMTP accepts a MAIL command with the BINARYMIME body-value, it agrees to preserve all bits in each octet passed using the BDAT command. Once a receiver-SMTP supporting the BINARYMIME service extension accepts a message containing binary material, the receiver-SMTP MUST deliver or relay the message in such a way as to preserve all bits in each octet.
送信側SMTPは、バイナリMIMEメッセージはMAILコマンドで「BINARYMIME」の値を有する身体パラメータを送信することによって、トランスポート符号化せずに送信することを要求してもよいです。レシーバSMTPがBINARYMIME本体値でメールコマンドを受け付けると、各オクテットのすべてのビットを保持することに同意BDATコマンドを使用して渡されます。レシーバSMTP BINARYMIMEサービス拡張をサポートするバイナリ材料を含むメッセージを受け入れると、受信側SMTPは、各オクテットのすべてのビットを保持するようにメッセージを配信又は中継しなければなりません。
BINARYMIME cannot be used with the DATA command. If a DATA command is issued after a MAIL command containing the body-value of "BINARYMIME", a 503 "Bad sequence of commands" response MUST be sent. The resulting state from this error condition is indeterminate and the transaction MUST be reset with the RSET command.
BINARYMIMEは、DATAコマンドで使用することはできません。 DATAコマンドが「BINARYMIME」、503「のコマンドの悪いシーケンス」のボディ-値を含むMAILコマンドの後に発行された場合の応答を送らなければなりません。このエラー条件から得られた状態は不確定であり、トランザクションはRSETコマンドでリセットする必要があります。
It is especially important when using BINARYMIME 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><LF>. Any transformation of text into non-
canonical MIME to observe local storage conventions MUST be reversed
before sending as BINARYMIME. Some line-oriented shortcuts will
break if used with BINARYMIME. A sender-SMTP MUST use the canonical
encoding for a given MIME content-type. In particular, text/* MUST
be sent with <CR><LF> terminated lines.
Note: Although CR and LF do not necessarily represent ends of text lines in BDAT chunks and use of the binary transfer encoding is allowed, the RFC 2781 prohibition against using a UTF-16 charset within the text top-level media type remains.
注：CRやLFは、必ずしもトップレベルのメディアタイプが残っているテキスト内でUTF-16文字セットを使用してに対して、許可されているRFC 2781禁止BDATチャンクとバイナリ転送エンコードの使用のテキスト行の端部を表すものではないが。
The syntax of the extended MAIL command is identical to the MAIL command in [RFC821], except that a BODY=BINARYMIME parameter and value MUST be added. The complete syntax of this extended command is defined in [ESMTP].
拡張メールコマンドの構文は、BODY = BINARYMIMEパラメータと値が追加されなければならないことを除いて、[RFC821]でMAILコマンドと同じです。この拡張コマンドの完全な構文は[ESMTP]で定義されています。
If a receiver-SMTP does not indicate support the BINARYMIME message format then the sender-SMTP MUST NOT, under any circumstances, send binary data.
受信側SMTPがBINARYMIMEのメッセージ・フォーマットをサポートして示すものではありません場合は、送信側SMTPは、どのような状況の下で、バイナリデータを送ってはいけません。
If the receiver-SMTP does not support BINARYMIME and the message to be sent is a MIME object with a binary encoding, a sender-SMTP has three options with which to forward the message. First, if the receiver-SMTP supports the 8bit-MIMEtransport extension [8bit] and the content is amenable to being encoded in 8bit, the sender-SMTP may implement a gateway transformation to convert the message into valid 8bit-encoded MIME. Second, it may implement a gateway transformation to convert the message into valid 7bit-encoded MIME. Third, it may treat this as a permanent error and handle it in the usual manner for delivery failures. The specifics of MIME content-transfer-encodings, including transformations from Binary MIME to 8bit or 7bit MIME are not described by this RFC; the conversion is nevertheless constrained in the following ways:
レシーバSMTPがBINARYMIMEをサポートしていないと送信されるメッセージは、バイナリエンコーディングとMIMEオブジェクトである場合、送信側SMTPは、メッセージを転送すると、3つのオプションを有しています。受信側SMTPは8ビット・MIMEtransport延長[8ビット]をサポートしており、コンテンツが8ビットで符号化されるのに適している場合まず、送信側SMTPは、有効な8ビットでエンコードされたMIMEにメッセージを変換するゲートウェイ変換を実装することができます。第二に、それは有効な7ビットでエンコードされたMIMEにメッセージを変換するゲートウェイ変換を実装することができます。第三に、それは永続的なエラーとしてこれを扱い、配信の失敗のための通常の方法でそれを処理することができます。 8ビットのバイナリMIMEから変換または7ビットMIMEを含むMIMEコンテンツ転送符号化の詳細は、このRFCによって記述されていません。変換は、それにもかかわらず、次の方法で拘束されています。
1. The conversion MUST cause no loss of information; MIME transport encodings MUST be employed as needed to insure this is the case.
1.変換は、情報の損失を引き起こしてはなりません。このような場合は保証するために必要なMIME輸送エンコーディングを使用しなければなりません。
2. The resulting message MUST be valid 7bit or 8bit MIME. In particular, the transformation MUST NOT result in nested Base-64 or Quoted-Printable content-transfer-encodings.
2.得られたメッセージは、有効な7ビットまたは8ビットMIMEなければなりません。具体的には、変換は、ネストされたベース64又は引用印刷可能コンテンツ転送エンコーディングをもたらすてはいけません。
Note that at the time of this writing there are no mechanisms for converting a binary MIME object into an 8-bit MIME object. Such a transformation will require the specification of a new MIME content-transfer-encoding.
これを書いている時点で、8ビットのMIMEオブジェクトにバイナリMIMEオブジェクトを変換するためのメカニズムが存在しないことに留意されたいです。そのような変換は、新しいMIMEコンテンツ転送エンコードの仕様を必要とします。
If the MIME message contains a "Binary" content-transfer-encoding and the BODY parameter does not indicate BINARYMIME, the message MUST be accepted. The message SHOULD be returned to the sender with an appropriate DSN. The message contents MAY be returned to the sender if the offending content can be mangled into a legal DSN structure. "Fixing" and forwarding the offending content is beyond the scope of this document.
MIMEメッセージは、「バイナリ」のコンテンツ転送エンコーディングとBINARYMIMEを示すものではありませんBODYパラメータが含まれている場合、メッセージは受け入れなければなりません。メッセージは、適切なDSNを送信者に返されるべきである（SHOULD）。問題のあるコンテンツが法的DSN構造にマングルできるのであれば、メッセージの内容は、送信者に返されることがあります。 「修正」と問題のあるコンテンツを転送することは、このドキュメントの範囲を超えています。
The following simple dialogue illustrates the use of the large message extension to send a short pseudo-RFC 822 message to one recipient using the CHUNKING extension:
次の簡単な対話がCHUNKING拡張を使用しての受信者に短い擬似RFC 822メッセージを送信するために大きなメッセージ拡張の使用を示します。
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 86 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, 86 octets received S: QUIT R: 221 Goodbye
R：<TCPポート25で接続を待つ> S：220 cnri.reston.va.us SMTPサービス準備S：EHLO ymir.claremont.edu R：250-cnri.reston.va R <サーバーへのオープン接続>。私たちは挨拶R：250 CHUNKING S：FROM MAIL：<Sam@Random.com> R：250 <Sam@Random.com>送信者OK S：RCPT TO：<Susan@Random.com> R：250 <スーザン@ランダム.COM>受信者OK S：BDAT 86 LAST S：TO：Susan@random.com <CR> <LF> S：から：Sam@random.com <CR> <LF> S：件名：これはbodylessテストメッセージであります<CR> <LF> R：OK、86オクテットSを受信250メッセージ：QUIT R：221さようなら
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とパイプラインの拡張を使用して、2人の受信者にBINARYMIMEオブジェクトを送信するために大きなメッセージ拡張の使用を示します。
R: <wait for connection on TCP port 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 S: (First 10000 octets of canonical MIME message data)
R：<TCPポート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 MAIL：<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> ...送信者とBINARYMIME OK R：250 <gvaudre@cnri.reston.va.us> ...受信者OK R：250 <jstewart@cnri.reston.va.us> ...受信者OK S：BDAT 100000 S：（標準的なMIMEメッセージデータの最初の10000オクテット）
S: BDAT 324 S: (Remaining 324 octets of canonical MIME message data) S: BDAT 0 LAST R: 250 100000 octets received R: 250 324 octets received R: 250 Message OK, 100324 octets received S: QUIT R: 221 Goodbye
S：BDAT 324 S：Sを（カノニカルMIMEメッセージデータの324オクテットの残り）：BDAT 0 LAST R：250 100000オクテットRを受け取っ：QUIT R：221さようならOK、100324オクテットSを受信250メッセージ：250個の324オクテットはRを受け
This extension is not known to present any additional security issues not already endemic to electronic mail and present in fully conforming implementations of [RFC821], or otherwise made possible by [MIME].
この拡張は、[MIME]によって可能になるの完全準拠の実装[RFC821]、または他の方法で既に電子メールに流行と存在しない追加のセキュリティ上の問題を提示することは知られていません。
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995.
[BINARY]ヴォードルイユ、G.、RFC 1830、1995年8月 "大規模およびバイナリMIMEメッセージの送信のためのSMTPサービス拡張"。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME] Borenstein、N.とN.フリード、 "多目的インターネットメール拡張（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[SUBMIT] Gellens、R.及びJ. Klensin、 "メッセージ送信"、RFC 2476、1998年12月。
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
[ESMTP] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.およびD.クロッカー、 "SMTPサービス拡張"、RFC 1869、1995年11月。
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[8BIT] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.およびD.クロッカー、 "8ビット・MIMEtransportためのSMTPサービス拡張"、RFC 1652、1994年7月。
[PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining", RFC 2920, September 2000.
[PIPE]フリード、N.、 "コマンドパイプラインのためのSMTPサービス拡張"、RFC 2920、2000年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Gregory M. Vaudreuil Lucent Technologies 17080 Dallas Parkway Dallas, TX 75248-1905
グレゴリーM.ヴォードルイユルーセント・テクノロジーズ17080のダラスパークウェイダラス、TX 75248から1905
Phone/Fax: +1-972-733-2722 EMail: GregV@ieee.org
電話/ FAX：+ 1-972-733-2722 Eメール：GregV@ieee.org
Appendix A - Changes from RFC 1830
付録A - RFC 1830からの変更点
Numerous editorial changes including required intellectual property boilerplate and revised authors contact information
必要な知的財産定型および改訂された著者の連絡先情報を含む多数の編集上の変更
Corrected the simple chunking example to use the correct number of bytes. Updated the pipelining example to illustrate use of the BDAT 0 LAST construct.
正しいバイト数を使用する単純なチャンク化の例を修正。 BDAT 0 LASTコンストラクトの使用を説明するためにパイプラインの例を更新しました。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。