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 大きなバイナリのMIMEメッセージを送信するための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. この文書はインターネット共同体に対してインターネット標準トラックのプロ トコルを規定し、改善のための議論と助言を求める。このプロトコルの標準化 の段階と状態については"Internet Official Protocol Standards" (STD1)の 現在の版を参照してほしい。この文書の配布に制限はない。 Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 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つの拡張を定義す る。最初の拡張により、DATAコマンドの代わりに、効果的に大きな MIME(Multipurpose Internet MailExtensions)メッセージを送るための"BDAT" と呼ばれるものを利用することをSMTPクライアントとサーバが取り決めること ができる。2つ目の拡張では、バイナリ送信エンコーディングを用いる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ワーキンググループ内での議論から得られた規格である。RFC1830に 書かれた成果のプロトコルは、既存のMIME実装に実施されたバイナリコンテン ト送信エンコーディングの堅牢性についての疑問のため、当時実験プロトコル と位置づけられた。MIMEが成熟してきたこととバイナリコンテント転送エンコー ディングの別の利用法が実施されてきているので、バイナリESMTPが標準化ト ラックになるよう期待された。 Vaudreuil Standards Track [Page 1] RFC 3030 Binary ESMTP December 2000 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"は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 1. Overview 1. 俯瞰 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メッセージ[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 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やquoted-printableにエンコードするためのオーバーヘッドを 避ける必要がある。 Vaudreuil Standards Track [Page 2] RFC 3030 Binary ESMTP December 2000 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サービスに2つの拡張を定義する[ESMTP]に定義されたメカニ ズムを用いる手段で、SMTPサーバ(受信SMTP)がメッセージチャンク(chunk, ぶ つ切りの意味)の転送モードをサポートし、バイナリメッセージの受信をサポー トしていることを宣言して良く、その時SMTPクライアント(送信SMTP)が自由に 使える。 2. Framework for the Large Message Extensions 大きなメッセージ用拡張のためのフレームワーク The following service extension is hereby defined: これにより、以下のサービス拡張が定義される： 1) The name of the data chunking service extension is "CHUNKING". 1) データchunkのサービス拡張の名前は"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) BDATという新しいSMTP動詞が、[RFC821]の"DATA"コマンドの代用品として 定義される。BDAT動詞は2つの引数を取る。最初の引数はバイナリデータの chunkの長さをオクテットで示す。二つ目のオプションの引き数はデー タのぶつぎりが最後であることを示す。 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メッセージ提出[Submit]で使われてもよい。 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コマンドをサポートし続け なければならない(MUST)。クライアントは、もしそうすることを望むなら ば、CHUNKING拡張をサポートするサーバに、適切にエンコードされた転送 にDATAを用いるのも自由である。 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ビット、8ビットMIME, 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がCHUNKING拡張を用いて大きなメッセージを送る(MAILコマンドを用 いて)ことを望む時、まず受信SMTPにEHLOコマンドが発行される。 もしも受信SMTPがEHLOコマンドに対して250コードを返し、かつEHLOキーワー ドの値でCHUNKINGを含む応答ならば、受信SMTPは、それがBDATコマンドをサポー トし、chunkメッセージの送信を受け入れることを示す。 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 Vaudreuil Standards Track [Page 3] RFC 3030 Binary ESMTP December 2000 octets. The message data is sent immediately after the trailing 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コマンドラインのに続いてすぐ送信される。受信側の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コマンドにおけるオプションのLASTパラメータは、これが送信メッセージ データの最後のchunkであることを示す。その最後のBDATコマンドは、追加で 送信すべきデータがないことを示すバイトカウント0であっても良い(MAY)。 BDAT LAST以降のBDATコマンドの送信は規則違反であり、503 "Bad sequence of commands"(まちがったコマンドの並び)の応答コードを返さなければならな い(MUST)。このエラーの結果として生じる状態は不確定である。続けるには、 RSETコマンドを送ってトランザクションをクリアしなければならない(MUST)。 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. メールトランザクション中、それぞれの成功したBDATデータブロックごとに 250応答が送信されなければならない(MUST)。もしBDATコマンドを受けとった 後に失敗が生じたならば、受信側のSMTPは受信し、適切な4XXないし5XXコード を送る前に関連するメッセージデータを捨てなければならない(MUST)。もし BDATchunkの応答で送り側SMTPに5XXないし4XXコードが送られたならば、トラ ンザクションは失敗したものと考え、送り側のSMTPは追加のBDATセグメントを 送信してはならない(MUST NOT)。もし受信側SMTPがコマンドパイプライン [PIPE]をサポートすると宣言しているならば、受信側はそれを受けとるための 準備をし、BDATが失敗した以降のパイプラインに既にあるBDATのchunkを捨て なければならない。 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セグメントが受信されてからのみ報告され得る。それゆえ、期待されるエ ンドトゥエンドの与えられた帯域に妥当なchunkのサイズを選ぶことが重要で ある。 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コマンドや関連し たメッセージデータをCHUNKINGが扱えないシステムに送ることは、受信側の 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コマンドを発行してトランザクションをクリアしなければならない(MUST)。 RSETコマンドが最初のBDATより後、BDAT LASTより前に発行された時には、そ のトランザクション中送られたすべてのセグメントをクリアし、セッションを リセットする。 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 Vaudreuil Standards Track [Page 4] RFC 3030 Binary ESMTP December 2000 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 Bad sequence of commands"が発行されなければならない(MUST)。このエラーによっ て生じる状態は不定である。続ける前にRSETコマンドでトランザクションをク リアしなければならない(MUST)。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 . 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. 1つのメッセージのためのローカルなストレージのサイズは、ローカルのスト レージの約束事によって送られたメッセージの実際のサイズを正しく反映する。 特に、BDATコマンドで送られたテキストメッセージは、で行が区切ら れた正規のMIMEフォーマットで送られなければならない(MUST)。一時にメッセー ジ全体を正規のフォーマットへ変換するのは不可能かもしれない。CHUNKINGは メッセージを正規の形式にし、正確にバイト数を数え、一時に1つのchunkとし てメッセージを送るメカニズムを提供する。 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が実際 よりも大きなchunkのサイズを示したならば、受信側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が実際より小さなchunkのサイズを示したなら、受信側SMTPは メッセージデータの残りを無効なコマンドとして解釈するだろう。メッセージ データの残りはバイナリかもしれず、従って辞書式のパーサは任意のオクテッ トからなる行を受信し、処理し、拒否する準備をしておかなければならない (MUST)。 3. Framework for the Binary Service Extension バイナリサービス拡張のフレームワーク 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 Vaudreuil Standards Track [Page 5] RFC 3030 Binary ESMTP December 2000 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パラメータを定義している。この拡 張では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メッセージ提出[Submit]に利用されてもよい。 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 FROMコマンド行の最大長は、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はMAILコマンドで"BINARYMIME"の値を持つBODYパラメータを送る ことによる転送エンコードなしでバイナリMIMEメッセージが送られることを要 求するかもしれない。受信側SMTPがMAILコマンドでBINARYMIMEのボディ値を受 け入れた時には、BDATコマンドを用いることで、各オクテット中のすべてのビッ トが保存されることが同意される。一旦、BINARYMIMEサービス拡張をサポート する受信側SMTPがバイナリマテリアルを含むメッセージを受け入れたら、受信 側SMTPは各オクテットのすべてのビットを保存する方法でメッセージを配送な いしリレーしなければならない(MUST)。 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コマンドと共に利用され得ない。もしボディ値"BINARYMIME" を含むMAILコマンドの後でDATAコマンドが発行されたならば、"503 Bad sequence of commands"応答が送られなければならない(MUST)。このエラーの 状況からおこる結果の状態は不定であり、トランザクションはRSETコマンドで リセットされなければならない(MUST)。 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 . 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 terminated lines. BINARYMIMEを利用する際、MIMEメッセージそのものが正しく形成されているこ とを確実にすることが、特に重要である。特にテキストが、それぞれの行が 正しくで終わる標準的なエンコードであることが必須である。 ローカルストレージの約束に従うような非標準MIMEへのいかなる変換も、 BINARYMIMEとして送信される前に逆変換されなければならない(MUST)。 BINARYMIMEを用いたならば、いくつかの行指向のショートカットは壊れるだろ う。送り側SMTPは与えられたMIMEのcontent-typeに標準的なエンコードを用い なければならない(MUST)。特に、text/* は行の終わりにを送信しな ければならない(MUST)。 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. 注意：BDATのchunk中では、CRとLFにはテキスト行の終わりとしての重要な意 味がなく、バイナリ転送エンコードを利用することが許されているが、テキス トのトップレベルメディア中におけるUTF-16文字セットを用いる際のRFC 2781 の禁止事項は、未だに残る。 Vaudreuil Standards Track [Page 6] RFC 3030 Binary ESMTP December 2000 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]. 拡張されたMAILコマンドの構文は、BODY=BINARYMIMEパラメータと値が加えら れなければならない(MUST)以外は、[RFC 821]にある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は、いかなる状況であってもバイナリデータ を送信してはならない(MUST NOT)。 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ビッ トのMIME転送[8bit]の拡張をサポートし、かつ内容が8bitにエンコードされる のが素直な場合、送り側SMTPは、メッセージを8ビットでエンコードされた有 効なMIMEに変換するゲートウェイ変換を実装してもよい。2つ目に、メッセー ジを有効な、7ビットでエンコードされたMIMEへ変換するゲートウェイ変換を 実装してもよい。3つ目に、それを永続的なエラーとして扱い、配送失敗の普 通の方法で扱ってもよい。バイナリMIMEを8ビットないし7ビットMIMEへ変換す ることを含め、特定のMIMEl content-transfer-encodingはこの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. 変換により、情報の欠落を起こしてはならない(MUST)；その場合、MIME転 送エンコードは必要に応じてなされなければならない(MUST)。 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でなければな らない(MUST)。特に、変換はネストされたBase64やQuoted-Printableの content-transfer-encodingであってはならない(MUST NOT)。 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 content-transfer-encoding の仕様が必要となるだろう。 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メッセージが"バイナリ"のcontent-transfer-encodingを持ち、BODY パラメータがBINARYMIMEを示していないならば、メッセージは受けとられなけ ればならない(MUST)。そのメッセージは適切なDSNをつけて送り主に返される べきである(SHOULD)。もしも攻撃的な内容が正規のDSN構造を壊すかもしれな いならば、メッセージの内容は送り主に返されてもよい(MAY)。攻撃的なコン テンツを「直し」て転送することは、この文書の範囲外である。 Vaudreuil Standards Track [Page 7] RFC 3030 Binary ESMTP December 2000 4. Examples 4. 例 4.1 Simple Chunking 4.1 簡単なChunking 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拡張を用いて1人の受信者に短かい偽のRFC822 メッセージを送るために「大きなメッセージ拡張」を用いることを示している。 R: S: 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: R: 250 Sender ok S: RCPT TO: R: 250 Recipient ok S: BDAT 86 LAST S: To: Susan@random.com S: From: Sam@random.com S: Subject: This is a bodyless test message R: 250 Message OK, 86 octets received S: QUIT R: 221 Goodbye 4.2 Pipelining BINARYMIME 4.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拡張を用いて2人の受信者にBINARYMIME を送るために「大きなメッセージ拡張」を用いることを示している。 R: 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: BODY=BINARYMIME S: RCPT TO: S: RCPT TO: R: 250 ... Sender and BINARYMIME ok R: 250 ... Recipient ok R: 250 ... Recipient ok S: BDAT 100000 S: (First 10000 octets of canonical MIME message data) Vaudreuil Standards Track [Page 8] RFC 3030 Binary ESMTP December 2000 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 5. Security Considerations 5. セキュリティに関する考察 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]. この拡張について、電子メール固有の既存のもの以外の追加のセキュリティ問 題の存在は知られておらず、完全に[RFC 821]の実施によるもの、あるいは [MIME]によって可能にされるものが存在する。 6. References [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995. [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995. [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994. [PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining", RFC 2920, September 2000. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Vaudreuil Standards Track [Page 9] RFC 3030 Binary ESMTP December 2000 7. Author's Address Gregory M. Vaudreuil Lucent Technologies 17080 Dallas Parkway Dallas, TX 75248-1905 Phone/Fax: +1-972-733-2722 EMail: GregV@ieee.org Vaudreuil Standards Track [Page 10] RFC 3030 Binary ESMTP December 2000 Appendix A - Changes from 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. Vaudreuil Standards Track [Page 11] RFC 3030 Binary ESMTP December 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. 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. Vaudreuil Standards Track [Page 12] ----- 訳について この訳は、美森勇気 が行いました。利用は自由ですが、一 切の保証はしません。