RFC1653 日本語訳
1653 SMTP Service Extension for Message Size Declaration. J. Klensin,N. Freed, K. Moore. July 1994. (Format: TXT=17883 bytes) (Obsoletes RFC1427) (Obsoleted by RFC1870) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Klensin, WG Chair
Request for Comments: 1653 MCI
Obsoletes: 1427 N. Freed, Editor
Category: Standards Track Innosoft
K. Moore
University of Tennessee
July 1994
ワーキンググループJ.Klensin、コメントを求めるWG議長Requestをネットワークでつないでください: 1653年のMCIは以下を時代遅れにします。 1427年の解放されたN.エディタカテゴリ: 規格は1994年7月にテネシーのInnosoft K.ムーア大学を追跡します。
SMTP Service Extension for Message Size Declaration
メッセージサイズ宣言のための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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size.
このメモはSMTPクライアントとサーバがクライアントのメッセージサイズの見積りに基づくメッセージ(恐らく一時)を受け入れるのを断る機会をサーバに与えるために相互作用するかもしれないSMTPサービスと拡大を定義します。
1. Introduction
1. 序論
The MIME extensions to the Internet message protocol provide for the transmission of many kinds of data which were previously unsupported in Internet mail. One expected result of the use of MIME is that SMTP will be expected to carry a much wider range of message sizes than was previously the case. This has an impact on the amount of resources (e.g., disk space) required by a system acting as a server.
インターネットメッセージプロトコルへのMIME拡大は多くの種類の以前にインターネット・メールでサポートされなかったデータの伝達に備えます。 あるものは、MIMEの使用の結果がSMTPが以前にであるはるかに広い範囲のメッセージサイズを運ぶと予想されるということであると予想しました。ケース。 これはサーバとして作動するシステムによって必要とされたリソース(例えば、椎間腔)の量に影響を与えます。
This memo uses the mechanism defined in [5] to define extensions to
the SMTP service whereby a client ("sender-SMTP") may declare the
size of a particular message to a server ("receiver-SMTP"), after
which the server may indicate to the client that it is or is not
willing to accept the message based on the declared message size and
whereby a server ("receiver-SMTP") may declare the maximum message
size it is willing to accept to a client ("sender-SMTP").
このメモはクライアント(「送付者-SMTP」)がサーバがそれがそうであることをクライアントに示すかもしれないか、または宣言しているメッセージサイズに基づくメッセージを受け入れることを望んでいないサーバ(「受信機-SMTP」)に特定のメッセージのサイズを宣言するかもしれなくて、サーバ(「受信機-SMTP」)がそれが受け入れても構わないとクライアント(「送付者-SMTP」)と思っている最大のメッセージサイズを宣言するかもしれないSMTPサービスと拡大を定義するために[5]で定義されたメカニズムを使用します。
Klensin, Freed & Moore [Page 1] RFC 1653 SMTP Size Declaration July 1994
Klensin、解放されるのとムーア[1ページ]RFC1653SMTPサイズ宣言1994年7月
2. Framework for the Size Declaration Extension
2. サイズ宣言拡大のためのフレームワーク
The following service extension is therefore defined:
したがって、以下のサービス拡大は定義されます:
(1) the name of the SMTP service extension is "Message Size
Declaration";
(1) SMTPサービス拡張子の名前は「メッセージサイズ宣言」です。
(2) the EHLO keyword value associated with this extension is "SIZE";
(2) この拡大に関連しているEHLOキーワード価値は「サイズ」です。
(3) one optional parameter is allowed with this EHLO keyword value,
a decimal number indicating the fixed maximum message size in
bytes that the server will accept. The syntax of the parameter
is as follows, using the augmented BNF notation of [2]:
(3) 1つの任意のパラメタがこのEHLOキーワード価値(サーバが受け入れるバイトで表現される固定最大のメッセージサイズを示す10進数)で許容されています。 [2]の増大しているBNF記法を使用して、パラメタの構文は以下の通りです:
size-param ::= [1*DIGIT]
サイズ-param:、:= [1*ケタ]
A parameter value of 0 (zero) indicates that no fixed maximum
message size is in force. If the parameter is omitted no
information is conveyed about the server's fixed maximum message
size;
0(ゼロ)のパラメタ値は、どんな固定最大のメッセージサイズも有効でないことを示します。 パラメタが省略されるなら、情報は全くサーバの固定最大のメッセージサイズに関して伝えられません。
(4) one optional parameter using the keyword "SIZE" is added to the
MAIL FROM command. The value associated with this parameter is a
decimal number indicating the size of the message that is to be
transmitted. The syntax of the value is as follows, using the
augmented BNF notation of [2]:
(4) 「サイズ」というキーワードを使用する1つの任意のパラメタがコマンドからメールに追加されます。 このパラメタに関連している値は送られることになっているメッセージのサイズを示す10進数です。 [2]の増大しているBNF記法を使用して、価値の構文は以下の通りです:
size-value ::= 1*DIGIT
以下をサイズで評価してください:= 1*ケタ
(5) no additional SMTP verbs are defined by this extension.
(5) どんな追加SMTP動詞もこの拡大で定義されません。
The remainder of this memo specifies how support for the extension affects the behavior of an SMTP client and server.
このメモの残りは拡大のサポートがどうSMTPクライアントとサーバの働きに影響するかを指定します。
3. The Message Size Declaration service extension
3. Message Size Declarationサービス拡張子
An SMTP server may have a fixed upper limit on message size. Any attempt by a client to transfer a message which is larger than this fixed upper limit will fail. In addition, a server normally has limited space with which to store incoming messages. Transfer of a message may therefore also fail due to a lack of storage space, but might succeed at a later time.
SMTPサーバーはメッセージサイズに固定上限を持っているかもしれません。 これが上限を修理したより大きいメッセージを移すクライアントによるどんな試みも失敗するでしょう。 さらに、通常、サーバは入力メッセージを保存するスペースを制限しました。 メッセージの転送は、したがって、また、ストレージ不足スペースのため失敗しますが、後で成功するかもしれません。
A client using the unextended SMTP protocol defined in [1], can only be informed of such failures after transmitting the entire message to the server (which discards the transferred message). If, however, both client and server support the Message Size Declaration service extension, such conditions may be detected before any transfer is
クライアントが[1]で定義されたunextended SMTPプロトコルを使用して、サーバ(わたっているメッセージを捨てる)に全体のメッセージを送った後に、そのような失敗について知らすことができるだけです。 しかしながら、クライアントとサーバの両方が、Message Size Declarationサービスが拡大であるとサポートするなら、どんな転送も検出になる前にそのような状態は検出されるかもしれません。
Klensin, Freed & Moore [Page 2] RFC 1653 SMTP Size Declaration July 1994
Klensin、解放されるのとムーア[2ページ]RFC1653SMTPサイズ宣言1994年7月
attempted.
試みられる。
An SMTP client wishing to relay a large content may issue the EHLO command to start an SMTP session, to determine if the server supports any of several service extensions. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword value SIZE, then the Message Size Declaration extension is supported.
大きい内容をリレーしたがっているSMTPクライアントは、サーバがいくつかのサービス拡大のどれかをサポートするかどうか決定するためにSMTPセッションを始めるEHLOコマンドを発行するかもしれません。 サーバがコード250でEHLOコマンドに反応して、応答がEHLOキーワード値のSIZEを含んでいるなら、Message Size Declaration拡張子はサポートされます。
If a numeric parameter follows the SIZE keyword value of the EHLO response, it indicates the size of the largest message that the server is willing to accept. Any attempt by a client to transfer a message which is larger than this limit will be rejected with a permanent failure (552) reply code.
数値パラメタがEHLO応答のSIZEキーワード価値に続くなら、それはサーバが、受け入れても構わないと思っているという最も大きいメッセージのサイズを示します。 この限界より大きいメッセージを移すクライアントによるどんな試みも永久的な失敗(552)回答コードで拒絶されるでしょう。
A server that supports the Message Size Declaration extension will accept the extended version of the MAIL command described below. When supported by the server, a client may use the extended MAIL command (instead of the MAIL command as defined in [1]) to declare an estimate of the size of a message it wishes to transfer. The server may then return an appropriate error code if it determines that an attempt to transfer a message of that size would fail.
Message Size Declarationが拡大であるとサポートするサーバは以下で説明されたメールコマンドの拡張版を受け入れるでしょう。 いつがサーバによってサポートされて、クライアントは拡張メールコマンドを使用するかもしれません。(メッセージのサイズの見積りを宣言するために[1])で定義されるメールコマンドの代わりに、それは移したがっています。 そして、そのサイズに関するメッセージを移す試みが失敗することを決定するなら、サーバは適切なエラーコードを返すかもしれません。
4. Definitions
4. 定義
The message size is defined as the number of octets, including CR-LF pairs, but not the SMTP DATA command's terminating dot or doubled quoting dots, to be transmitted by the SMTP client after receiving reply code 354 to the DATA command.
メッセージサイズは八重奏の数と定義されます、SMTP DATAコマンドのものではなく、回答コード354をDATAコマンドに受け取った後にSMTPクライアントによって伝えられるようにドットを引用しながらドットを終えるか、または倍にされたCR-LF組を含んでいて。
The fixed maximum message size is defined as the message size of the largest message that a server is ever willing to accept. An attempt to transfer any message larger than the fixed maximum message size will always fail. The fixed maximum message size may be an implementation artifact of the SMTP server, or it may be chosen by the administrator of the server.
固定最大のメッセージサイズはサーバが、受け入れても構わないと思っているという最も大きいメッセージのメッセージサイズと定義されます。 固定最大のメッセージサイズより大きいどんなメッセージも移す試みはいつも失敗するでしょう。 固定最大のメッセージサイズはSMTPサーバーの実装人工物であるかもしれませんかそれがサーバの管理者によって選ばれるかもしれません。
The declared message size is defined as a client's estimate of the message size for a particular message.
宣言しているメッセージサイズは特定のメッセージのためにクライアントのメッセージサイズの見積りと定義されます。
4. The extended MAIL command
4. 拡張メールコマンド
The extended MAIL command is issued by a client when it wishes to inform a server of the size of the message to be sent. The extended MAIL command is identical to the MAIL command as defined in [1], except that a SIZE parameter appears after the address.
送られるべきメッセージのサイズのサーバを知らせたがっているとき、拡張メールコマンドはクライアントによって発行されます。 拡張メールコマンドは[1]で定義されるようにメールコマンドと同じです、SIZEパラメタがアドレスの後に現れるのを除いて。
Klensin, Freed & Moore [Page 3] RFC 1653 SMTP Size Declaration July 1994
Klensin、解放されるのとムーア[3ページ]RFC1653SMTPサイズ宣言1994年7月
The complete syntax of this extended command is defined in [5]. The esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by the syntax for size-value shown above.
この拡張コマンドの完全な構文は[5]で定義されます。 esmtp-キーワードは「サイズ」です、そして、上に示されたサイズ値のために構文でesmtp-値のための構文を与えます。
The value associated with the SIZE parameter is a decimal representation of the declared message size in octets. This number should include the message header, body, and the CR-LF sequences between lines, but not the SMTP DATA command's terminating dot or doubled quoting dots. Only one SIZE parameter may be specified in a single MAIL command.
SIZEパラメタに関連している値は八重奏で、宣言しているメッセージサイズの10進表現です。 この数はメッセージヘッダー、ボディー、およびSMTP DATAコマンドのものではなく、ドットを引用しながらドットを終えるか、または倍にされた系列の間のCR-LF系列を含むべきです。 ただ一つのメールコマンドで1つのSIZEパラメタだけを指定してもよいです。
Ideally, the declared message size is equal to the true message size. However, since exact computation of the message size may be infeasable, the client may use a heuristically-derived estimate. Such heuristics should be chosen so that the declared message size is usually larger than the actual message size. (This has the effect of making the counting or non-counting of SMTP DATA dots largely an academic point.)
理想的に、宣言しているメッセージサイズは真のメッセージサイズと等しいです。 しかしながら、メッセージサイズの正確な計算がinfeasableであるかもしれないので、クライアントは発見的に派生している見積りを使用するかもしれません。 そのような発見的教授法が選ばれるべきであるので、通常、宣言しているメッセージサイズは実際のメッセージサイズより大きいです。 (これには、SMTP DATAドットの勘定か非勘定を主にアカデミックなポイントにするという効果があります。)
NOTE: Servers MUST NOT use the SIZE parameter to determine end of content in the DATA command.
以下に注意してください。 サーバは、DATAコマンドにおける内容の終わりを決定するのにSIZEパラメタを使用してはいけません。
5.1 Server action on receipt of the extended MAIL command
5.1 拡張メールコマンドを受け取り次第サーバ動作
Upon receipt of an extended MAIL command containing a SIZE parameter, a server should determine whether the declared message size exceeds its fixed maximum message size. If the declared message size is smaller than the fixed maximum message size, the server may also wish to determine whether sufficient resources are available to buffer a message of the declared message size and to maintain it in stable storage, until the message can be delivered or relayed to each of its recipients.
SIZEパラメタを含む拡張メールコマンドを受け取り次第、サーバは、宣言しているメッセージサイズが固定最大のメッセージサイズを超えているかどうか決定するべきです。 また、宣言しているメッセージサイズが固定最大のメッセージサイズより小さいなら、サーバは、十分なリソースが宣言しているメッセージサイズに関するメッセージをバッファリングして、安定貯蔵でそれを維持するために利用可能であるかどうか決定したがっているかもしれません、受取人各人にメッセージを提供するか、またはリレーできるまで。
A server may respond to the extended MAIL command with any of the error codes defined in [1] for the MAIL command. In addition, one of the following error codes may be returned:
エラーコードのどれかがメールコマンドのための[1]で定義されている状態で、サーバは拡張メールコマンドに反応するかもしれません。 さらに、以下のエラーコードの1つを返すかもしれません:
(1) If the server currently lacks sufficient resources to accept a
message of the indicated size, but may be able to accept the
message at a later time, it responds with code "452
insufficient system storage".
(1) サーバが現在示されたサイズに関するメッセージを受け入れることができるくらいのリソースを欠いていますが、後でメッセージを受け入れることができるかもしれないなら、それはコードで「452の不十分なシステムストレージ」を反応させます。
(2) If the indicated size is larger than the server's fixed maximum
message size, the server responds with code "552 message size
exceeds fixed maximium message size".
(2) 示されたサイズがサーバの固定最大のメッセージサイズより大きいなら、サーバはコードで「サイズが超えているmaximiumメッセージサイズが固定された552メッセージ」を反応させます。
A server is permitted, but not required, to accept a message which is, in fact, larger than declared in the extended MAIL command, such
サーバは、事実上、拡張メールコマンドで宣言されるより大きいメッセージを受け入れるのに受入れられますが、必要ではありません、そのようなもの
Klensin, Freed & Moore [Page 4] RFC 1653 SMTP Size Declaration July 1994
Klensin、解放されるのとムーア[4ページ]RFC1653SMTPサイズ宣言1994年7月
as might occur if the client employed a size-estimation heuristic which was inaccurate.
クライアントが不正確であったサイズ見積りヒューリスティックを使うなら起こるので。
5.2 Client action on receiving response to extended MAIL command
5.2 拡張メールコマンドへの応答を受けることへのクライアント動作
The client, upon receiving the server's response to the extended MAIL command, acts as follows:
拡張メールコマンドへのサーバの応答を受けるとき、クライアントは以下の通りに行動します:
(1) If the code "452 insufficient system storage" is returned, the
client should next send either a RSET command (if it wishes to
attempt to send other messages) or a QUIT command. The client
should then repeat the attempt to send the message to the server
at a later time.
(1) コードであるなら「452の不十分なシステムストレージ」を返して、クライアントは発信するべきです。次に、RSETコマンド(他のメッセージを送るのを試みたいなら)かQUITコマンドのどちらかが発信します。 そして、クライアントは後でメッセージをサーバに送る試みを繰り返すべきです。
(2) If the code "552 message exceeds fixed maximum message size" is
received, the client should immediately send either a RSET
command (if it wishes to attempt to send additional messages),
or a QUIT command. The client should then declare the message
undeliverable and return appropriate notification to the sender
(if a sender address was present in the MAIL command).
(2) 「最大のメッセージサイズが固定されて、552メッセージは超えている」コードが受け取られているなら、クライアントがすぐに、RSETコマンド(追加メッセージを送るのを試みたいなら)かQUITコマンドのどちらかを送るべきです。 クライアントは、次に、メッセージが「非-提出物」であると宣言して、適切な通知を送付者に返すべきです(送付者アドレスがメールコマンドで存在していたなら)。
A successful (250) reply code in response to the extended MAIL command does not constitute an absolute guarantee that the message transfer will succeed. SMTP clients using the extended MAIL command must still be prepared to handle both temporary and permanent error reply codes (including codes 452 and 552), either immediately after issuing the DATA command, or after transfer of the message.
拡張メールコマンドに対応したうまくいっている(250)回答コードはメッセージ転送が成功するという絶対保証を構成しません。 拡張メールコマンドを使用しているSMTPクライアントはまだDATAコマンドを発行する直後、メッセージの転送の後に一時的なものと同様に永久的なエラー応答コードを扱う(コード452と552を含んでいます)用意ができていなければなりません。
5.3 Messages larger than the declared size.
宣言しているサイズより大きい5.3のメッセージ。
Once a server has agreed (via the extended MAIL command) to accept a message of a particular size, it should not return a 552 reply code after the transfer phase of the DATA command, unless the actual size of the message transferred is greater than the declared message size. A server may also choose to accept a message which is somewhat larger than the declared message size.
サーバが、特定のサイズに関するメッセージを受け入れるのにいったん同意すると(拡張メールコマンドで)、DATAコマンドの転送フェーズの後に552回答コードを返すべきではありません、移されたメッセージの実サイズが宣言しているメッセージサイズほど大きくない場合。 また、サーバは、宣言しているメッセージサイズよりいくらか大きいメッセージを受け入れるのを選ぶかもしれません。
A client is permitted to declare a message to be smaller than its actual size. However, in this case, a successful (250) reply code is no assurance that the server will accept the message or has sufficient resources to do so. The server may reject such a message after its DATA transfer.
クライアントが、メッセージが実サイズより小さいと宣言することが許可されています。 しかしながら、この場合、うまくいっている(250)回答コードはサーバには、メッセージを受け入れるか、またはそうすることができるくらいのリソースがあるという保証ではありません。 DATAが移した後にサーバはそのようなメッセージを拒絶するかもしれません。
5.4 Per-recipient rejection based on message size.
5.4 1受取人あたりの拒絶はメッセージサイズを基礎づけました。
A server that implements this extension may return a 452 or 552 reply code in response to a RCPT command, based on its unwillingness to accept a message of the declared size for a particular recipient.
この拡大を実装するサーバは、特定の受取人のために宣言しているサイズに関するメッセージを受け入れるためにRCPTコマンドに対応して気がすすまないことに基づいて452か552回答コードを返すかもしれません。
Klensin, Freed & Moore [Page 5] RFC 1653 SMTP Size Declaration July 1994
Klensin、解放されるのとムーア[5ページ]RFC1653SMTPサイズ宣言1994年7月
(1) If a 452 code is returned, the client may requeue the message for
later delivery to the same recipient.
(1) 452コードが返されるなら、クライアントは後の配送へのメッセージを同じ受取人へ「再-列に並ばせ」るかもしれません。
(2) If a 552 code is returned, the client may not requeue the message
for later delivery to the same recipient.
(2) 552コードが返されるなら、クライアントは後の配送へのメッセージを同じ受取人へ「再-列に並ばせ」ないかもしれません。
6. Minimal usage
6. 最小量の用法
A "minimal" client may use this extension to simply compare its (perhaps estimated) size of the message that it wishes to relay, with the server's fixed maximum message size (from the parameter to the SIZE keyword in the EHLO response), to determine whether the server will ever accept the message. Such an implementation need not declare message sizes via the extended MAIL command. However, neither will it be able to discover temporary limits on message size due to server resource limitations, nor per-recipient limitations on message size.
「最小量」のクライアントは、サーバがメッセージを受け入れるかどうか決定するために単にサーバのものが修理されている状態で最大のメッセージサイズをリレーしたがっているという(パラメタからEHLO応答におけるSIZEキーワードまで)メッセージの(恐らく概算)のサイズを比較するのにこの拡張子を使用するかもしれません。 そのような実装は拡張メールコマンドでメッセージサイズを宣言する必要はありません。 しかしながら、どちらも、それはメッセージサイズでサーバリソース制限、および受取人あたりのメッセージサイズ制限における一時的な限界を発見できないでしょう。
A minimal server that employs this service extension may simply use the SIZE keyword value to inform the client of the size of the largest message it will accept, or to inform the client that there is no fixed limit on message size. Such a server must accept the extended MAIL command and return a 552 reply code if the client's declared size exceeds its fixed size limit (if any), but it need not detect "temporary" limitations on message size.
このサービス拡大を使う最小量のサーバは、受け入れる中で最も大きいメッセージのサイズについてクライアントに知らせるか、または固定限界が全くメッセージサイズにないことをクライアントに知らせるのに単にSIZEキーワード価値を使用するかもしれません。 クライアントの宣言しているサイズが固定サイズ限界(もしあれば)を超えているなら、そのようなサーバは、拡張メールコマンドを受け入れて、552回答コードを返さなければなりませんが、それはメッセージサイズに「一時的な」制限を検出する必要はありません。
The numeric parameter to the EHLO SIZE keyword is optional. If the parameter is omitted entirely it indicates that the server does not advertise a fixed maximum message size. A server that returns the SIZE keyword with no parameter in response to the EHLO command may not issue a positive (250) response to an extended MAIL command containing a SIZE specification without first checking to see if sufficient resources are available to transfer a message of the declared size, and to retain it in stable storage until it can be relayed or delivered to its recipients. If possible, the server should actually reserve sufficient storage space to transfer the message.
EHLO SIZEキーワードへの数値パラメタは任意です。 パラメタが完全に省略されるなら、それは、サーバが固定最大のメッセージサイズの広告を出さないのを示します。 EHLOコマンドに対応してパラメタなしでSIZEキーワードを返すサーバは、十分なリソースが宣言しているサイズに関するメッセージを移して、安定貯蔵でそれを保有するためにそれを受取人にリレーするか、または提供できるまで利用可能であるかどうか確認するために最初にチェックしないでSIZE仕様を含む拡張メールコマンドへの積極的な(250)応答を発行しないかもしれません。 できれば、サーバは実際にメッセージを移すことができるくらいの集積スペースを予約するべきです。
7. Example
7. 例
The following example illustrates the use of size declaration with some permanent and temporary failures.
以下の例はいくつかの永久的で一時的な失敗をサイズ宣言の使用に入れます。
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
C: EHLO ymir.claremont.edu
S: 250-sigurd.innosoft.com
S: TCPポート25>Cにおける接続のための<待ち: サーバ>Sとの<のオープンな接続: 220 sigurd.innosoft.com--サーバSMTP(PMDF V4.2-6#1992)C: EHLO ymir.claremont.edu S: 250-sigurd.innosoft.com
Klensin, Freed & Moore [Page 6] RFC 1653 SMTP Size Declaration July 1994
Klensin、解放されるのとムーア[6ページ]RFC1653SMTPサイズ宣言1994年7月
S: 250-EXPN
S: 250-HELP
S: 250 SIZE 1000000
C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
S: 250 Address Ok.
C: RCPT TO:<ned@innosoft.com>
S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
C: RCPT TO:<ned@ymir.claremont.edu>
S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
C: RCPT TO:<ned@hmcvax.claremont.edu>
S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
C: DATA
S: 354 Send message, ending in CRLF.CRLF.
...
C: .
S: 250 Some recipients OK
C: QUIT
S: 250 Goodbye
S: 250-EXPN S: 250助けS: 250 サイズ1000000C: FROM:<ned@thor.innosoft.com に郵送してください、gt;、サイズ=500000秒間: 250はOKを記述します。 C: RCPT TO:<ned@innosoft.com 、gt;、S: 250 ned@innosoft.com OK。 缶のaccomodateの500000バイトのメッセージC: RCPT TO:<ned@ymir.claremont.edu 、gt;、S: 552チャンネルサイズ限界は超えていました: ned@YMIR.CLAREMONT.EDU C: RCPT TO:<ned@hmcvax.claremont.edu 、gt;、S: 452 不十分なチャンネル格納: ned@hmcvax.CLAREMONT.EDU C: データS: CRLF.CRLFに終わって、354はメッセージを送ります。 ... C: . S: 250 何人かの受取人がCを承認します: Sをやめてください: 250さよなら
8. Security Considerations
8. セキュリティ問題
The size declaration extensions described in this memo can conceivably be used to facilitate crude service denial attacks. Specifically, both the information contained in the SIZE parameter and use of the extended MAIL command make it somewhat quicker and easier to devise an efficacious service denial attack. However, unless implementations are very weak, these extensions do not create any vulnerability that has not always existed with SMTP. In addition, no issues are addressed involving trusted systems and possible release of information via the mechanisms described in this RFC.
粗雑なサービス否定攻撃を容易にするのに多分このメモで説明されたサイズ宣言拡張子は使用できます。 明確に、SIZEパラメタに含まれた情報と拡張メールコマンドの使用の両方で、いくらか迅速であって、効果を生じているサービス否定攻撃について工夫するのは、より簡単です。 しかしながら、実現がそれほど弱くない場合、これらの拡大はSMTPと共にいつも存在するというわけではなかった少しの脆弱性も作成しません。 さらに、問題は、全くこのRFCで説明されたメカニズムで信じられたシステムと可能な情報公開にかかわりながら、記述されません。
9. Acknowledgements
9. 承認
This document was derived from an earlier Working Group draft contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot Lear, Marshall T. Rose, and Einar Stefferud provided extensive comments in response to earlier drafts of both this and the previous memo.
以前の作業部会の草稿貢献からこのドキュメントを得ました。 ジム・コンクリン、デーヴ・クロッカー、ニール・ケーティン、エリオットリア、マーシャル・T.ローズ、およびEinar Stefferudはこれと前のメモの両方の以前の草稿に対応して大規模なコメントを提供しました。
10. References
10. 参照
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[1] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[2] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
[3] Borenstein、N.と解放されたN.、「マルチパーパスインターネットメールエクステンション」、RFC1521、Bellcore、Innosoft、1993年9月。
Klensin, Freed & Moore [Page 7] RFC 1653 SMTP Size Declaration July 1994
Klensin、解放されるのとムーア[7ページ]RFC1653SMTPサイズ宣言1994年7月
[4] Moore, K., "Representation of Non-ASCII Text in Internet Message
Headers", RFC 1522, University of Tennessee, September 1993.
[4] ムーア、K.、「インターネットメッセージヘッダーの非ASCIIテキストの表現」、RFC1522、テネシー大学、1993年9月。
[5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
"SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach
Consulting, Inc., Network Management Associates, Inc., Silicon
Graphics, Inc., July 1994.
Klensin(J.)が解放した[5]、Inc.、ネットワークマネージメントに相談するRFC1651、MCI、Innosoft、ドーヴァーが無能にするN.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPサービス拡張子」がInc.を関連づけます、シリコングラフィックス、1994年7月。
[6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
974, BBN, January 1986.
[6] ヤマウズラ、C.が「ルート設定とドメインシステムを郵送する」、STD14、RFC974、BBN、1月1986日
11. Chair, Editor, and Authors' Addresses
11. 議長、エディタ、および作者のアドレス
John Klensin, WG Chair MCI Data Services Division 2100 Reston Parkway, 6th floor Reston, VA 22091 USA
ジョンKlensin、WG議長MCI Data Services事業部2100レストン6階のレストン、ヴァージニア22091パークウェイ(米国)
Phone:: 1 703 715 7361 Fax: +1 703 715 7435 EMail: klensin@mci.net
以下に電話をしてください: 1、703 715、7361Fax: +1 7435年の703 715メール: klensin@mci.net
Ned Freed, Editor Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA
解放されたエディタのSouth Westコビーナ、Innosoftの国際Inc.1050の東ガーヴェーアベニューカリフォルニア91790ネッド(米国)
Phone:: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com
以下に電話をしてください: +1 818 919、3600Fax: +1 3614年の818 919メール: ned@innosoft.com
Keith Moore Computer Science Dept. University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA
キースムーアコンピュータサイエンス部 テネシー大学107歌曲Hallテネシー37996-1301ノクスビル(米国)
EMail: moore@cs.utk.edu
メール: moore@cs.utk.edu
Klensin, Freed & Moore [Page 8]
Klensin、フリード、およびムーア[8ページ]
一覧
スポンサーリンク
