[要約] RFC 3030は、大きなおよびバイナリMIMEメッセージの送信のためのSMTPサービス拡張に関するものです。このRFCの目的は、SMTPプロトコルを使用して大きなおよびバイナリデータを効率的に送信するための拡張を提供することです。
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
大型およびバイナリマイムメッセージの送信用のSMTPサービス拡張機能
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.
Copyright（c）The Internet Society（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（Simple Mail転送プロトコル）サービスに2つの拡張機能を定義します。最初の拡張機能により、SMTPクライアントとサーバーは、「BDAT」と呼ばれるデータコマンドの代替案の使用を交渉して、大規模なMIME（多目的インターネットメールエクステンション）メッセージを効率的に送信することができます。2番目の拡張機能は、BDATコマンドを利用して、バイナリ転送エンコードを使用するMIMEメッセージの交渉された送信を許可します。このドキュメントは、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は、エンコードされていない8ビットMIMEメッセージ[8ビット]の送信のためのそのような拡張の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 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の使用の予想される結果の1つは、インターネットメールシステムが非常に大きなメールメッセージを伝えることが期待されることです。このようなトランザクションでは、メッセージの終了を検出するために送信および受信すると、「crlf。crlf」シーケンスのメッセージがスキャンされるという要件を排除するというパフォーマンスベースの要望があります。
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.
大きなメッセージを送信する必要性とは無関係に、インターネットメールはますますマルチメディアになります。Base64のオーバーヘッドと、バイナリメッセージ処理をサポートするホスト間でSMTPを介してMIMEメッセージ形式を使用して送信されたバイナリオブジェクトの引用プリント可能なエンコードを回避する必要があります。
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.
このメモは、[ESMTP]で定義されたメカニズムを使用して、SMTPサービスに2つの拡張機能を定義し、SMTPサーバー（ "Receiver-SMTP"）がメッセージチャンキング伝送モードのサポートとバイナリメッセージの受信のサポートを宣言することができます。クライアント（ "Sender-SMTP"）は自由に使用できます。
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, 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]の「データ」コマンドの代替として定義されます。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データコマンドを引き続きサポートする必要があります。クライアントは、データを使用して、適切にエンコードされたサーバーに適切にエンコードされたサーバーに転送され、希望する場合はチャンク拡張機能をサポートするサーバーに転送できます。
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.
チャンクサービス拡張機能により、データコマンドに代わるBDAT代替品を使用できます。この拡張機能は、7ビット、8ビットマイム、バイナリマイムなど、あらゆるメッセージに使用できます。
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が（メールコマンドを使用して）チャンク拡張機能を使用して大きなメッセージを送信したい場合、最初にehloコマンドをレシーバー-SMTPに発行します。レシーバー-SMTPがコード250でEHLOコマンドに応答し、応答にEHLOキーワード値チャンキングが含まれる場合、レシーバー-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.
すべてのメールと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の最後の後に送信された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コマンドを受信した後に障害が発生した場合、Receiver-SMTPは、適切な5XXまたは4XXコードを送信する前に、関連するメッセージデータを受け入れて破棄する必要があります。BDATチャンクに応じて5xxまたは4xxコードが送信者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.
注：ディスクフルまたは差し迫ったシャットダウンなどのレシーバー-SMTPのエラーは、BDATセグメントを受信した後にのみ報告できます。したがって、予想されるエンドツーエンドの帯域幅を考えると、合理的なチャンクサイズを選択することが重要です。
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を送信することが重要です。BDATコマンドと関連するメッセージデータを非チャンキング対応システムに違法に送信すると、レシーバーSMTPは、バイナリデータを含む潜在的に非常に長いESMTPコマンドラインであるかのように、関連するメッセージデータを解析します。
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コマンドを発行する必要があります。RSTコマンドは、最初のBDATの後に発行された場合、およびBDATの最後の前に発行された場合、そのトランザクション中に送信されたすべてのセグメントをクリアし、セッションをリセットします。
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.
データとBDATコマンドは、同じトランザクションでは使用できません。現在のトランザクションの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形式で送信する必要があります。メッセージ全体を一度に標準形式に変換することはできない場合があります。チャンキングは、メッセージを標準的なフォームに変換し、バイトを正確にカウントし、メッセージを一度に単一のチャンクに送信するメカニズムを提供します。
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.
注：正しいバイトカウントが不可欠です。Sender-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.
Sender-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サービス拡張機能は、「チャンキング」サービス拡張機能でのみ使用できます。
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]メールコマンドのボディパラメーターを定義します。この拡張機能は、ボディパラメーター「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) コマンドラインからのメールの最大長さは、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メッセージを送信するように要求する場合があります。受信者SMTPがBinaryMimeのボディ値を使用してメールコマンドを受け入れると、BDATコマンドを使用して通過した各オクテットのすべてのビットを保持することに同意します。BinaryMime Service拡張機能をサポートする受信機-SMTPがバイナリ素材を含むメッセージを受け入れると、受信機-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は、データコマンドでは使用できません。「binarymime」のボディ値を含むメールコマンドの後にデータコマンドが発行された場合、503「コマンドの悪いシーケンス」応答を送信する必要があります。このエラー条件から得られる状態は不確定であり、トランザクションはRSTコマンドでリセットする必要があります。
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.
BinaryMimeを使用してMimeメッセージ自体が適切に形成されることを確認する場合に特に重要です。特に、<cr> <lf>で適切に終了した各ラインでテキストを正規にエンコードすることが不可欠です。バイナリマイムとして送信する前に、ローカルストレージの規則を観察するために、テキストを非標準的なMIMEに変換することを逆転させる必要があります。BinaryMimeで使用すると、いくつかのライン指向のショートカットが壊れます。Sender-SMTPは、特定のMIMEコンテンツタイプの標準エンコードを使用する必要があります。特に、テキスト/*は<cr> <lf>終端行で送信する必要があります。
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は必ずしもBDATチャンクのテキスト行の端を表しているわけではありませんが、バイナリ転送エンコードの使用が許可されていますが、テキストのトップレベルのメディアタイプ内でUTF-16 charsetを使用することに対するRFC 2781の禁止は残りです。
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].
拡張メールコマンドの構文は、[RFC821]のメールコマンドと同一ですが、Body = binaryMimeパラメーターと値を追加する必要があることを除きます。この拡張コマンドの完全な構文は、[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がバイナリマイムメッセージ形式をサポートしていない場合、送信者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ビットミメトランスポーツ拡張[8ビット]をサポートし、コンテンツが8ビットでエンコードされる可能性がある場合、送信者SMTPはゲートウェイ変換を実装して、メッセージを有効な8ビットエンコードMIMEに変換する場合があります。第二に、メッセージを有効な7ビットエンコードMIMEに変換するためにゲートウェイ変換を実装する場合があります。第三に、これを永続的なエラーとして扱い、配達の故障のために通常の方法でそれを処理するかもしれません。バイナリMIMEから8ビットまたは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. 変換は情報の損失を引き起こさない必要があります。必要に応じて、マイムトランスポートエンコーディングを使用する必要があります。
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.
この執筆時点では、バイナリMIMEオブジェクトを8ビット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メッセージに「バイナリ」コンテンツ転移エンコードが含まれており、ボディパラメーターがバイナリMIMEを示していない場合、メッセージを受け入れる必要があります。メッセージは、適切なDSNを使用して送信者に返送する必要があります。問題のコンテンツを、問題のコンテンツを法的な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:
次の簡単なダイアログは、大きなメッセージ拡張機能を使用して、チャンク拡張機能を使用して1人の受信者に短い擬似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
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:
次のダイアログは、チャンキングとパイプラインの拡張機能を使用して2人の受信者にバイナリマイムオブジェクトを送信するための大きなメッセージ拡張機能の使用を示しています。
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)
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
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].
この拡張機能は、電子メールにまだ固有のない追加のセキュリティ問題を提示し、[RFC821]の完全に適合する実装に存在するか、[MIME]によって可能にされたことは知られていません。
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995.
[Binary] Vaudreuil、G。、「大型およびバイナリMIMEメッセージの送信用SMTPサービス拡張」、RFC 1830、1995年8月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821] Postel、J。、「Simple Mail Transfer Protocol」、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] Crocker、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. Freed、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[提出] Gellens、R。およびJ. Klensin、「Message Submission」、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.、Freed、N.、Rose、M.、Stefferud、E。およびD. Crocker、「SMTP Service Extensions」、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.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining", RFC 2920, September 2000.
[Pipe] Freed、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Gregory M. Vaudreuil Lucent Technologies 17080 Dallas Parkway Dallas, TX 75248-1905
Gregory M. Vaudreuil Lucent Technologies 17080ダラスパークウェイダラス、テキサス75248-1905
Phone/Fax: +1-972-733-2722
EMail: 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の最後のコンストラクトの使用を説明しました。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。