RFC3030 日本語訳
3030 SMTP Service Extensions for Transmission of Large and Binary MIMEMessages. G. Vaudreuil. December 2000. (Format: TXT=23405 bytes) (Obsoletes RFC1830) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Vaudreuil Request for Comments: 3030 Lucent Technologies Obsolete: 1830 December 2000 Category: Standards Track
コメントを求めるワーキンググループG.ボードルイの要求をネットワークでつないでください: 3030 ルーセントテクノロジーズは以下を時代遅れにします。 1830 2000年12月のカテゴリ: 標準化過程
SMTP Service Extensions for Transmission of Large and Binary MIME Messages
大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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つの拡大を定義します。 "BDAT"は、最初の拡大が、SMTPクライアントとサーバがDATAコマンドへの代替手段の使用を交渉するのを可能にすると呼びました、効率的に大きいMIME(マルチパーパスインターネットメールエクステンション)にメッセージを送るために。 2番目の拡大は2進の転送コード化を使うMIMEメッセージの交渉された発信を可能にするBDATコマンドを利用します。 このドキュメントは、RFC1830をアップデートして、時代遅れにすることを意図します。
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実装で配布されたBinary Content転送コード化の丈夫さに関する質問のため実験的であるとして分類されました。 MIMEが熟して、Binary Content転送コード化の他の用途が配布されるのに従って、これらの関心は鎮められました。 このドキュメントで、Binary ESMTPが標準化過程になると予想されます。
Vaudreuil Standards Track [Page 1] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[1ページ]。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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. 概要… 2 2. 大きいメッセージ拡張子のためのフレームワーク… 3 3. 2進のサービス拡大のためのフレームワーク… 5 4. 例… 8 4.1の簡単な分魂化… 8 4.2 パイプライン処理BINARYMIME… 8 5. セキュリティ問題… 9 6. 参照… 9 7. 作者のアドレス… 10 8. 付録A--RFC1830からの変化… 11 9. 完全な著作権宣言文… 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プロトコルを広げてあります。 RFC1652は暗号化されていない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.
大きいメッセージを送る必要性の如何にかかわらず、インターネット・メールはますますマルチメディアです。 base64のオーバーヘッドとMIMEメッセージ・フォーマットが2進のメッセージ処理をサポートするホストの間でSMTPの上で使用させられた2進のオブジェクトの引用されて印刷可能なコード化を避ける必要があります。
Vaudreuil Standards Track [Page 2] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[2ページ]。
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サービスと2つの拡大を定義して、Binaryのレセプションのために、次に、SMTPクライアント(「送付者-SMTP」)が自由に使用できるメッセージをサポートするために[ESMTP]で定義されたメカニズムを使用します。
2. Framework for the Large Message Extensions
2. 大きいメッセージ拡張子のためのフレームワーク
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"
bdat-cmd:、:= "BDAT"SP塊サイズ[SPエンドマーカー]CR LF塊サイズ:、:= 1*DIGITエンドマーカー:、:= 「最後」
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拡張子をサポートするサーバにコード化された転送に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ビット、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がCHUNKING拡張子を使用することで大きいメッセージを送りたがっているとき(メールコマンドを使用します)、それは最初に、受信機-SMTPにEHLOコマンドを発行します。 受信機-SMTPがコード250でEHLOコマンドに応じて、応答が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
すべてのメールとRCPT応答を集めて、処理した後に、メッセージに一連のBDATコマンドを使用させます。 コマンドが1つの必要な議論、データ・セグメントの正確な長さを取るBDAT
Vaudreuil Standards Track [Page 3] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[3ページ]。
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.
八重奏。 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コマンドに関する任意のLASTパラメタは、これがメッセージデータの最後の送られるべき塊であることを示します。 最後のBDATコマンドには、ゼロが、送られるどんな追加データもないのを示すバイト・カウントがあるかもしれません。 どんなBDATコマンドもBDAT LASTが不法になった後に送られて、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.
メールトランザクションの中でそれぞれのうまくいっているBDATデータ・ブロックに250応答を送らなければなりません。 BDATコマンドが受け取られていた後に失敗が起こるなら、適切な5XXか4XXにコードを送る前に、受信機-SMTP MUSTは関連メッセージデータを受け入れて、捨てます。 5XXか4XXコードがBDAT塊に対応して送付者-SMTPによって受け取られるなら、トランザクションは失敗されていると考えられるべきです、そして、送付者SMTP MUST NOTはどんな追加BDATセグメントも送ります。 受信機SMTPが、コマンド連続送信[PIPE]、受信機SMTP MUSTのサポートが既に失敗した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を送るのは重要です。 非CHUNKINGのできるシステムへの不法にBDATコマンドを送って、関連メッセージデータはまるでそれが潜在的にまさしくそのロング(バイナリ・データを含むESMTPコマンドライン)であるかのように受信機-SMTP構文解析における結果に関連メッセージデータを望んでいます。
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コマンドを発行しなければなりません。 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
同じトランザクションにDATAとBDATコマンドを使用できません。 BDATの後に経常取引のためにDATA声明を発行するなら、「コマンドの悪い系列」を発行しなければならない503です。 この誤りから生じる状態は不確定です。 RSETコマンドに発信しなければなりません。
Vaudreuil Standards Track [Page 4] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[4ページ]。
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を使用するとき、禁止が全くありません、それらが同じトランザクションで混ぜられない限り。
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コマンドと共に送られたテキスト・メッセージを送らなければなりません。 すぐに全体のメッセージを正準な形式に変換するのは可能でないかもしれません。 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は無効のコマンドとしてメッセージデータの残りを解釈するでしょう。 メッセージデータの残りが2進であるかもしれないことに注意してください、そして、受信するようにそのような辞書編集のパーサを準備しなければならないとき、処理してください、そして、任意の八重奏の系列を拒絶してください。
3. Framework for the Binary Service Extension
3. 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) [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
5) [8BIT]はメールコマンドのためのBODYパラメタを定義します。 この拡大はBODYパラメタ、"BINARYMIME"のために加算値を定義します。 中このパラメタに関連している値の"BINARYMIME"が、このメッセージが2進のMIMEメッセージであることを示す、(。
Vaudreuil Standards Track [Page 5] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[5ページ]。
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]:
任意の八重奏内容を送る[MIME)への徹底順守。 [RFC822]のABNF記法を使用して、価値の改訂された構文は以下の通りです:
body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
以下をボディーで評価してください:= 「7ビット」/"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 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は、2進のMIMEメッセージがメールコマンドと共に"BINARYMIME"の値があるBODYパラメタを送るのによる輸送コード化なしで送られるよう要求するかもしれません。 受信機-SMTPがBINARYMIMEボディー価値でメールコマンドを受け入れるとき、それは、BDATコマンドを使用することで通過された各八重奏ですべてのビットを保存するのに同意します。 BINARYMIMEサービスが拡大であるとサポートする受信機-SMTPがいったん2進の材料を含むメッセージを受け入れると、受信機-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.
DATAコマンドと共にBINARYMIMEを使用できません。 "BINARYMIME"のボディー値を含むメールコマンドの後にDATAコマンドを発行するなら、503「コマンドの悪い系列」応答を送らなければなりません。 このエラー条件からの結果として起こる状態は不確定です、そして、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.
MIMEメッセージ自体が適切に形成されるのを保証するのにBINARYMIMEを使用するとき、それは特に重要です。 各系列が<CR><LF>で適切に終えられている状態でテキストが正準にコード化されるのは、特に、不可欠です。 BINARYMIMEとして発信する前に、地方のストレージコンベンションを観測する非正準なMIMEへのテキストのどんな変換も逆にしなければなりません。 BINARYMIMEと共に使用されると、いくつかの系列指向の近道が壊れるでしょう。 送付者-SMTP MUSTは与えられたMIME content typeに正準なコード化を使用します。 特に、<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塊におけるテキスト行の終わりを表すというわけではありません、そして、2進の転送コード化の使用は許されていますが、テキストトップレベルメディアタイプの中でUTF-16 charsetを使用することに対する2781年のRFC禁止は残っています。
Vaudreuil Standards Track [Page 6] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[6ページ]。
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が、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つのオプションがあります。 まず最初に8ビットのMIMEtransport拡張子[8ビット]と内容が受信機-SMTPサポートであるなら8ビットでコード化されるのに従順である、送付者-SMTPは有効な8ビットでコード化されたMIMEにメッセージを変換するためにゲートウェイ変換を実装するかもしれません。 2番目に、それは、有効な7ビットでコード化されたMIMEにメッセージを変換するためにゲートウェイ変換を実装するかもしれません。 3番目に、それは、永続エラーとしてこれを扱って、常法で配信障害によってそれを扱うかもしれません。 MIMEの満足している転送encodingsの詳細、8ビットかBinary MIMEから7ビットの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輸送encodingsを使わなければなりません。
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かQuoted印刷可能な満足している転送encodingsをもたらしてはいけません。
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オブジェクトに2進の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メッセージが「バイナリー」満足している転送コード化を含んでいて、BODYパラメタがBINARYMIMEを示さないなら、メッセージを受け入れなければなりません。 SHOULDを通信させてください。適切なDSNをもっている送付者に返します。 法的なDSN構造に怒っている内容を台無しにすることができるなら、メッセージ内容を送付者に返すかもしれません。 怒っている内容を「修理し」て、転送するのはこのドキュメントの範囲を超えています。
Vaudreuil Standards Track [Page 7] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[7ページ]。
4. Examples
4. 例
4.1 Simple Chunking
4.1 簡単な分魂化
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拡張子を使用することで短い疑似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 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における接続のための<待ち: サーバ>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: BDAT86は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、86の八重奏がSを受けました: Rをやめてください: 221さよなら
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拡張子を使用することでBINARYMIMEオブジェクトを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)
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:<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秒間: (最初に、正準なMIMEメッセージデータの10000の八重奏)
Vaudreuil Standards Track [Page 8] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[8ページ]。
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: BDAT324秒間: (正準なMIMEメッセージデータの324の八重奏のままで残っています) S: BDAT0はRを持続します: 250 100000の八重奏がRを受けました: 250 324の八重奏がRを受けました: 250 Message OK、100324の八重奏がSを受けました: Rをやめてください: 221さよなら
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].
この拡大が既に電子メールへの風土病の、そして、[RFC821]の実装を完全に従わせることにおいて現在でないか、または別の方法で[MIME]によって可能にされなかった問題をどんな追加担保にも提示するのが知られません。
6. References
6. 参照
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995.
[2進]のボードルイ、G.、「大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子」、RFC1830、1995年8月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[まねます] Borenstein、N.、およびN.フリード、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[提出します] GellensとR.とJ.Klensin、「メッセージ提案」、RFC2476、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サービス拡張子」、RFC1869、1995年11月。
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
Klensin(J.)が解放した[8ビット]、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは8ビット-MIMEtransportのために拡大を修理します」、RFC1652、1994年7月。
[PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining", RFC 2920, September 2000.
解放された[パイプ]、N.、「コマンド連続送信のためのSMTPサービス拡張子」、RFC2920、2000年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Vaudreuil Standards Track [Page 9] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[9ページ]。
7. Author's Address
7. 作者のアドレス
Gregory M. Vaudreuil Lucent Technologies 17080 Dallas Parkway Dallas, TX 75248-1905
ダラスParkwayダラス、グレゴリーM.ボードルイルーセントテクノロジーズ17080テキサス75248-1905
Phone/Fax: +1-972-733-2722 EMail: GregV@ieee.org
電話/Fax: +1-972-733-2722 メールしてください: GregV@ieee.org
Vaudreuil Standards Track [Page 10] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[10ページ]。
Appendix A - Changes from RFC 1830
付録A--RFC1830からの変化
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.
適度のバイト数を使用するために簡単な分魂化の例を修正しました。 BDAT0LAST構造物の使用を例証するためにパイプライン処理の例をアップデートしました。
Vaudreuil Standards Track [Page 11] RFC 3030 Binary ESMTP December 2000
ボードルイ規格はESMTP2000年12月にRFC3030バイナリーを追跡します[11ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Vaudreuil Standards Track [Page 12]
ボードルイ標準化過程[12ページ]
一覧
スポンサーリンク