RFC2920 日本語訳

Network Working Group                                          N. Freed
Request for Comments: 2920                                     Innosoft
STD: 60                                                  September 2000
Obsoletes: 2197
Category: Standards Track

ネットワークワーキンググループN.はコメントを求める要求を解放しました: 2920Innosoft STD: 60 2000年9月は以下を時代遅れにします。 2197年のカテゴリ: 標準化過程

             SMTP Service Extension for Command Pipelining

コマンド連続送信のための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 an extension to the Simple Mail Transfer Protocol
   (SMTP) service whereby a server can indicate the extent of its
   ability to accept multiple commands in a single Transmission Control
   Protocol (TCP) send operation. Using a single TCP send operation for
   multiple commands can improve SMTP performance significantly.

このメモはサーバが(TCP)が操作を送るただ一つの通信制御プロトコルにおける複数のコマンドを受け入れる性能の範囲を示すことができるシンプルメールトランスファプロトコル(SMTP)サービスと拡大を定義します。 複数のコマンドにTCPが操作を送るシングルを使用するのはSMTP性能をかなり向上させることができます。

1.  Introduction

1. 序論

   Although SMTP is widely and robustly deployed, certain extensions may
   nevertheless prove useful. In particular, many parts of the Internet
   make use of high latency network links.  SMTP's intrinsic one
   command-one response structure is significantly penalized by high
   latency links, often to the point where the factors contributing to
   overall connection time are dominated by the time spent waiting for
   responses to individual commands (turnaround time).

SMTPは広さと強壮に配布されますが、それにもかかわらず、ある拡大は有用であることが分かるかもしれません。 特に、インターネットの多くの地域が高い潜在ネットワークリンクを利用します。 SMTPの本質的な1つのコマンド-1つの応答の構造が、個々のコマンド(ターンアラウンドタイム)への応答を待っているのに費やされる時までに総合的な接続時間まで貢献する要素が支配されるところで高い潜在リンクによってかなり罰せられて、しばしば肝心です。

   In the best of all worlds it would be possible to simply deploy SMTP
   client software that makes use of command pipelining: batching up
   multiple commands into single TCP send operations. Unfortunately, the
   original SMTP specification [RFC-821] did not explicitly state that
   SMTP servers must support this. As a result a non-trivial number of
   Internet SMTP servers cannot adequately handle command pipelining.
   Flaws known to exist in deployed servers include:

最も良い世界では、SMTPがコマンド連続送信を利用するクライアントソフトウェアであると単に配布するのが可能でしょう: 倍数へのバッチングは、操作を送るように独身のTCPに命令します。 残念ながら、当初のSMTP仕様[RFC-821]は、SMTPサーバーがこれをサポートしなければならないと明らかに述べませんでした。 その結果、重要な数のインターネットSMTPサーバーは適切にコマンド連続送信を扱うことができません。 配布しているサーバで存在するのが知られている欠点は:

Freed                       Standards Track                     [Page 1]

RFC 2920              SMTP for Command Pipelining         September 2000

解放された規格は2000年9月にコマンド連続送信のためにRFC2920SMTPを追跡します[1ページ]。

    (1)   Connection handoff and buffer flushes in the middle of the
          SMTP dialogue.  Creation of server processes for incoming SMTP
          connections is a useful, obvious, and harmless implementation
          technique. However, some SMTP servers defer process forking
          and connection handoff until some intermediate point in the
          SMTP dialogue.  When this is done material read from the TCP
          connection and kept in process buffers can be lost.

(1) SMTP対話の途中での接続移管とバッファ水洗。 入って来るSMTP接続のためのサーバプロセスの作成は役に立って、明白で、無害な実装のテクニックです。 しかしながら、いくつかのSMTPサーバーがSMTP対話でプロセス分岐と接続移管を何らかの中間的ポイントまで延期します。 これがTCP接続から読まれた材料が完了していて、閉じ込められるとき、プロセスバッファを失うことができます。

    (2)   Flushing the TCP input buffer when an SMTP command fails. SMTP
          commands often fail but there is no reason to flush the TCP
          input buffer when this happens.  Nevertheless, some SMTP
          servers do this.

(2) SMTPコマンドが失敗するとき、TCPを洗い流すと、バッファは入力されました。 SMTPコマンドはしばしば失敗しますが、これが起こるとき、TCP入力バッファを洗い流す理由が全くありません。 それにもかかわらず、いくつかのSMTPサーバーがこれをします。

    (3)   Improper processing and promulgation of SMTP command failures.
          For example, some SMTP servers will refuse to accept a DATA
          command if the last RCPT TO command fails, paying no attention
          to the success or failure of prior RCPT TO command results.
          Other servers will accept a DATA command even when all
          previous RCPT TO commands have failed. Although it is possible
          to accommodate this sort of behavior in a client that employs
          command pipelining, it does complicate the construction of the
          client unnecessarily.

(3) SMTPの不適当な処理と発布は失敗を命令します。 例えば、最後のRCPT TOコマンドが失敗すると、いくつかのSMTPサーバーが、DATAコマンドを受け入れるのを拒否するでしょう、先のRCPT TOコマンド結果の成否に関する注意を全く向けないで。 前のすべてのRCPT TOコマンドが失敗さえしたとき、他のサーバはDATAコマンドを受け入れるでしょう。 コマンド連続送信を使うクライアントにこの種類の振舞いを収容するのが可能ですが、それは不必要にクライアントの工事を複雑にします。

   This memo uses the mechanism described in [RFC-1869] to define an
   extension to the SMTP service whereby an SMTP server can declare that
   it is capable of handling pipelined commands. The SMTP client can
   then check for this declaration and use pipelining only when the
   server declares itself capable of handling it.

このメモはSMTPサーバーがpipelinedコマンドを扱うことができると宣言できるSMTPサービスと拡大を定義するために[RFC-1869]で説明されたメカニズムを使用します。 サーバが、それ自体がそれを扱うことができると宣言するときだけ、SMTPクライアントは、次に、この宣言がないかどうかチェックして、パイプライン処理を使用できます。

1.1.  Requirements Notation

1.1. 要件記法

   This document occasionally uses terms that appear in capital letters.
   When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   appear capitalized, they are being used to indicate particular
   requirements of this specification. A discussion of the meanings of
   the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the
   terms "MUST NOT" and "SHOULD NOT" are logical extensions of this
   usage.

このドキュメントは時折大文字で現れる用語を使用します。 “MUST"という用語、「必須NOT」、“SHOULD"である、「」 「5月」は大文字で書かれるように見えて、それらは、この仕様の特定の要件を示すのに使用されるべきです。 用語“MUST"、“SHOULD"、および「5月」の意味の議論は[RFC-1123]に現れます。 そして、「必須NOT」という用語、「」 この用法は論理的な拡大があるべきですか?

2.  Framework for the Command Pipelining Extension

2. コマンド連続送信拡大のためのフレームワーク

   The Command Pipelining extension is defined as follows:

Command Pipelining拡張子は以下の通り定義されます:

    (1)   the name of the SMTP service extension is Pipelining;

(1) SMTPサービス拡張子の名前はPipeliningです。

    (2)   the EHLO keyword value associated with the extension is
          PIPELINING;

(2) 拡大に関連しているEHLOキーワード価値はPIPELININGです。

Freed                       Standards Track                     [Page 2]

RFC 2920              SMTP for Command Pipelining         September 2000

解放された規格は2000年9月にコマンド連続送信のためにRFC2920SMTPを追跡します[2ページ]。

    (3)   no parameter is used with the PIPELINING EHLO keyword;

(3) パラメタは全くPIPELINING EHLOキーワードと共に使用されません。

    (4)   no additional parameters are added to either the MAIL FROM or
          RCPT TO commands.

(4) どんな追加パラメタもMAIL FROMかRCPT TOコマンドに追加されません。

    (5)   no additional SMTP verbs are defined by this extension; and,

(5) どんな追加SMTP動詞もこの拡大で定義されません。 そして

    (6)   the next section specifies how support for the extension
          affects the behavior of a server and client SMTP.

(6) 次のセクションは拡大のサポートがどうサーバとクライアントSMTPの動きに影響するかを指定します。

3.  The Pipelining Service Extension

3. パイプライン処理サービス拡大

   When a client SMTP wishes to employ command pipelining, it first
   issues the EHLO command to the server SMTP. If the server SMTP
   responds with code 250 to the EHLO command, and the response includes
   the EHLO keyword value PIPELINING, then the server SMTP has indicated
   that it can accommodate SMTP command pipelining.

クライアントSMTPがコマンド連続送信を使いたがっているとき、それは最初に、サーバSMTPにEHLOコマンドを発行します。 サーバSMTPがコード250でEHLOコマンドに応じて、応答がEHLOキーワード値のPIPELININGを含んでいるなら、サーバSMTPは、SMTPコマンド連続送信を収容できるのを示しました。

3.1.  Client use of pipelining

3.1. パイプライン処理のクライアント使用

   Once the client SMTP has confirmed that support exists for the
   pipelining extension, the client SMTP may then elect to transmit
   groups of SMTP commands in batches without waiting for a response to
   each individual command. In particular, the commands RSET, MAIL FROM,
   SEND FROM, SOML FROM, SAML FROM, and RCPT TO can all appear anywhere
   in a pipelined command group.  The EHLO, DATA, VRFY, EXPN, TURN,
   QUIT, and NOOP commands can only appear as the last command in a
   group since their success or failure produces a change of state which
   the client SMTP must accommodate. (NOOP is included in this group so
   it can be used as a synchronization point.)

一度、クライアントSMTPは、サポートがパイプライン処理拡大のために存在すると確認したことがあって、次に、クライアントSMTPは、それぞれの個々のコマンドへの応答を待たないでバッチにおけるSMTPコマンドのグループを伝えるのを選ぶかもしれません。 特に、コマンドのRSET、MAIL FROM、SEND FROM、SOML FROM、SAML FROM、およびRCPT TOはpipelined指揮機関でどこでもすべて現れることができます。 それらの成否がクライアントSMTPが収容しなければならない状態の変化を発生させるので、EHLO、DATA、VRFY、EXPN、TURN、QUIT、およびNOOPコマンドは持続コマンドとしてグループに載ることができるだけです。 (NOOPは同期ポイントとしてそれを使用できるようにこのグループに含まれています。)

   Additional commands added by other SMTP extensions may only appear as
   the last command in a group unless otherwise specified by the
   extensions that define the commands.

別の方法でコマンドを定義する拡大で指定されない場合、他のSMTP拡張子で加えられた追加コマンドは持続コマンドとしてグループに載っているだけであるかもしれません。

   The actual transfer of message content is explicitly allowed to be
   the first "command" in a group. That is, a RSET/MAIL FROM sequence
   used to initiate a new message transaction can be placed in the same
   group as the final transfer of the headers and body of the previous
   message.

メッセージ内容の実際の転送は最初に、グループにおける「コマンド」であることが明らかに許容されています。 すなわち、新しいメッセージトランザクションを開始するのに使用されるRSET/MAIL FROM系列は前のメッセージのヘッダーとボディーの最終的な転送と同じグループに置くことができます。

   Client SMTP implementations that employ pipelining MUST check ALL
   statuses associated with each command in a group. For example, if
   none of the RCPT TO recipient addresses were accepted the client must
   then check the response to the DATA command -- the client cannot
   assume that the DATA command will be rejected just because none of
   the RCPT TO commands worked.  If the DATA command was properly
   rejected the client SMTP can just issue RSET, but if the DATA command

パイプライン処理を使うクライアントSMTP実装はグループにおける各コマンドに関連しているすべての状態をチェックしなければなりません。 例えば、次に、RCPT TO受取人アドレスのいずれも受け入れられなかったなら、クライアントはDATAコマンドへの応答をチェックしなければなりません--クライアントは、RCPT TOコマンドのどれかが働いていただけではないのでDATAコマンドが拒絶されると仮定できません。 DATAコマンドが適切に拒絶されたなら、クライアントSMTPはただRSETを発行できますが、DATAであるなら、命令してください。

Freed                       Standards Track                     [Page 3]

RFC 2920              SMTP for Command Pipelining         September 2000

解放された規格は2000年9月にコマンド連続送信のためにRFC2920SMTPを追跡します[3ページ]。

   was accepted the client SMTP should send a single dot.

受け入れて、クライアントSMTPはただ一つのドットを送るはずです。

   Command statuses MUST be coordinated with responses by counting each
   separate response and correlating that count with the number of
   commands known to have been issued.  Multiline responses MUST be
   supported. Matching on the basis of either the error code value or
   associated text is expressly forbidden.

コマンドの数が発行された状態で知られている重要であるそれぞれの別々の応答を数えて、関連するのによる応答でコマンド状態を調整しなければなりません。 マルチライン応答をサポートしなければなりません。 どちらかに基づいて誤りコード値か関連テキストを合わせるのは明白に禁じられます。

   Client SMTP implementations MAY elect to operate in a nonblocking
   fashion, processing server responses immediately upon receipt, even
   if there is still data pending transmission from the client's
   previous TCP send operation. If nonblocking operation is not
   supported, however, client SMTP implementations MUST also check the
   TCP window size and make sure that each group of commands fits
   entirely within the window. The window size is usually, but not
   always, 4K octets.  Failure to perform this check can lead to
   deadlock conditions.

データがクライアントの前のTCPからのトランスミッションまでまだあっても、SMTP実装がすぐ領収書にサーバ応答を処理して、「非-妨げ」ファッションで手術するのを選ぶかもしれないクライアントは操作を送ってください。 「非-妨げ」るなら、操作はしかしながら、また実装がチェックしなければならないクライアントSMTPにTCPウィンドウサイズをサポートして、コマンドの各グループが完全に窓の中で合うのを確実にしないことです。 いつも、4Kでない、しかし、通常、ウィンドウサイズは八重奏です。 このチェックを実行しない場合、行き詰まり状態につながることができます。

   Clients MUST NOT confuse responses to multiple commands with
   multiline responses. Each command requires one or more lines of
   response, the last line not containing a dash between the response
   code and the response string.

クライアントは複数のコマンドへの応答をマルチライン応答に間違えてはいけません。 各コマンドは応答(応答コードと応答ストリングの間にダッシュを含まない最終ライン)の1つ以上の系列を必要とします。

3.2.  Server support of pipelining

3.2. パイプライン処理のサーバサポート

   A server SMTP implementation that offers the pipelining extension:

パイプライン処理拡大を提供するサーバSMTP実装:

    (1)   MUST respond to commands in the order they are received from
          the client.

(1)は中のコマンドにクライアントから受け取られていた状態でオーダーを反応させなければなりません。

    (2)   SHOULD elect to store responses to grouped RSET, MAIL FROM,
          SEND FROM, SOML FROM, SAML FROM, and RCPT TO commands in an
          internal buffer so they can sent as a unit.

(2) SHOULDは、一体にして送って、選ぶことができるように内部のバッファにおける分類されたRSET、MAIL FROM、SEND FROM、SOML FROM、SAML FROM、およびRCPT TOコマンドへの応答を保存するのを選びます。

    (3)   SHOULD issue a positive response to the DATA command if and
          only if one or more valid RCPT TO addresses have been
          previously received.

そして、(3) SHOULDがDATAコマンドへの積極的な応答を発行する、以前に1つ以上の有効なRCPT TOアドレスを受け取った場合にだけ。

    (4)   MUST NOT, after issuing a positive response to a DATA command
          with no valid recipients and subsequently receiving an empty
          message, send any message whatsoever to anybody.

有効な受取人なしでDATAコマンドへの積極的な応答を発行して、次に空のメッセージを受け取った後に、(4)は全くどんなメッセージもだれにも送ってはいけません。

    (5)   MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN, TURN,
          QUIT, and NOOP.

(5)はEHLO、DATA、VRFY、EXPN、TURN、QUIT、およびNOOPへの応答をバッファリングしてはいけません。

    (6)   MUST NOT buffer responses to unrecognized commands.

(6)は認識されていないコマンドへの応答をバッファリングしてはいけません。

Freed                       Standards Track                     [Page 4]

RFC 2920              SMTP for Command Pipelining         September 2000

解放された規格は2000年9月にコマンド連続送信のためにRFC2920SMTPを追跡します[4ページ]。

    (7)   MUST send all pending responses immediately whenever the local
          TCP input buffer is emptied.

ローカルのTCP入力バッファが空にされているすぐときはいつも、(7)はすべての未定の応答を送らなければなりません。

    (8)   MUST NOT make assumptions about commands that are yet to be
          received.

(8)はまだ受け取っていてはいけないコマンドに関する仮定をしてはいけません。

    (9)   MUST NOT flush or otherwise lose the contents of the TCP input
          buffer under any circumstances whatsoever.

(9)はどうあっても全くTCP入力バッファのコンテンツを洗い流してはいけませんし、またそうでなければ、失ってはいけません。

    (10)  SHOULD issue response text that indicates, either implicitly
          or explicitly, what command the response matches.

(10) SHOULDは応答がどんなコマンドに合っているかをそれとなくか明らかに示す応答テキストを発行します。

   The overriding intent of these server requirements is to make it as
   easy as possible for servers to conform to these pipelining
   extensions.

これらのサーバ要件の最優先の意図はサーバがこれらのパイプライン処理拡大に従うのをできるだけ簡単にすることです。

4.  Examples

4. 例

   Consider the following SMTP dialogue that does not use pipelining:

パイプライン処理を使用しない以下のSMTP対話を考えてください:

   S: <wait for open connection>
   C: <open connection to server>
   S: 220 Innosoft.com SMTP service ready
   C: HELO dbc.mtview.ca.us
   S: 250 Innosoft.com
   C: MAIL FROM:<mrose@dbc.mtview.ca.us>
   S: 250 sender <mrose@dbc.mtview.ca.us> OK
   C: RCPT TO:<ned@innosoft.com>
   S: 250 recipient <ned@innosoft.com> OK
   C: RCPT TO:<dan@innosoft.com>
   S: 250 recipient <dan@innosoft.com> OK
   C: RCPT TO:<kvc@innosoft.com>
   S: 250 recipient <kvc@innosoft.com> OK
   C: DATA
   S: 354 enter mail, end with line containing only "."
    ...
   C: .
   S: 250 message sent
   C: QUIT
   S: 221 goodbye

S: 開いている接続>Cのための<待ち: サーバ>Sとの<のオープンな接続: 220 Innosoft.com SMTPは持ち合わせのCを修理します: HELO dbc.mtview.ca.us S: 250 Innosoft.com C: FROM:<mrose@dbc.mtview.ca.us に郵送してください、gt;、S: 250 sender <mrose@dbc.mtview.ca.us 、gt;、OK C: RCPT TO:<ned@innosoft.com 、gt;、S: 250 recipient <ned@innosoft.com 、gt;、OK C: RCPT TO:<dan@innosoft.com 、gt;、S: 250 recipient <dan@innosoft.com 、gt;、OK C: RCPT TO:<kvc@innosoft.com 、gt;、S: 250 recipient <kvc@innosoft.com 、gt;、OK C: データS: 「354はメール、系列含有だけがある終わりを入れる」、」 ... C: . S: 250メッセージはCを送りました: Sをやめてください: 221さよなら

   The client waits for a server response a total of 9 times in this
   simple example. But if pipelining is employed the following dialogue
   is possible:

クライアントはこの簡単な例で合計9回サーバ応答を待ちます。 しかし、パイプライン処理が採用しているなら、以下の対話は可能です:

   S: <wait for open connection>
   C: <open connection to server>
   S: 220 innosoft.com SMTP service ready

S: 開いている接続>Cのための<待ち: サーバ>Sとの<のオープンな接続: 220innosoft.com SMTPサービス準備ができています。

Freed                       Standards Track                     [Page 5]

RFC 2920              SMTP for Command Pipelining         September 2000

解放された規格は2000年9月にコマンド連続送信のためにRFC2920SMTPを追跡します[5ページ]。

   C: EHLO dbc.mtview.ca.us
   S: 250-innosoft.com
   S: 250 PIPELINING
   C: MAIL FROM:<mrose@dbc.mtview.ca.us>
   C: RCPT TO:<ned@innosoft.com>
   C: RCPT TO:<dan@innosoft.com>
   C: RCPT TO:<kvc@innosoft.com>
   C: DATA
   S: 250 sender <mrose@dbc.mtview.ca.us> OK
   S: 250 recipient <ned@innosoft.com> OK
   S: 250 recipient <dan@innosoft.com> OK
   S: 250 recipient <kvc@innosoft.com> OK
   S: 354 enter mail, end with line containing only "."
    ...
   C: .
   C: QUIT
   S: 250 message sent
   S: 221 goodbye

C: EHLO dbc.mtview.ca.us S: 250-innosoft.com S: 250 パイプライン処理C: FROM:<mrose@dbc.mtview.ca.us に郵送してください、gt;、C: RCPT TO:<ned@innosoft.com 、gt;、C: RCPT TO:<dan@innosoft.com 、gt;、C: RCPT TO:<kvc@innosoft.com 、gt;、C: データS: 250 sender <mrose@dbc.mtview.ca.us 、gt;、OK S: 250 recipient <ned@innosoft.com 、gt;、OK S: 250 recipient <dan@innosoft.com 、gt;、OK S: 250 recipient <kvc@innosoft.com 、gt;、OK S: 「354はメール、系列含有だけがある終わりを入れる」、」 ... C: . C: Sをやめてください: 250メッセージはSを送りました: 221さよなら

   The total number of turnarounds has been reduced from 9 to 4.

ターンアラウンドの総数は9〜4まで減少しました。

   The next example illustrates one possible form of behavior when
   pipelining is used and all recipients are rejected:

パイプライン処理が使用されているとき、次の例は1つの可能な形式の振舞いを例証します、そして、すべての受取人が拒絶されます:

   S: <wait for open connection>
   C: <open connection to server>
   S: 220 innosoft.com SMTP service ready
   C: EHLO dbc.mtview.ca.us
   S: 250-innosoft.com
   S: 250 PIPELINING
   C: MAIL FROM:<mrose@dbc.mtview.ca.us>
   C: RCPT TO:<nsb@thumper.bellcore.com>
   C: RCPT TO:<galvin@tis.com>
   C: DATA
   S: 250 sender <mrose@dbc.mtview.ca.us> OK
   S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
   S: 550 remote mail to <galvin@tis.com> not allowed
   S: 554 no valid recipients given
   C: QUIT
   S: 221 goodbye

S: 開いている接続>Cのための<待ち: サーバ>Sとの<のオープンな接続: 220 innosoft.com SMTPは持ち合わせのCを修理します: EHLO dbc.mtview.ca.us S: 250-innosoft.com S: 250 パイプライン処理C: FROM:<mrose@dbc.mtview.ca.us に郵送してください、gt;、C: RCPT TO:<nsb@thumper.bellcore.com 、gt;、C: RCPT TO:<galvin@tis.com 、gt;、C: データS: 250 sender <mrose@dbc.mtview.ca.us 、gt;、OK S: 550のリモートメール to <nsb@thumper.bellore.com 、gt;、Sを許容しません: 550のリモートメール to <galvin@tis.com 、gt;、Sを許容しません: 554 Cが与えられた有効な受取人がありません: Sをやめてください: 221さよなら

   The client SMTP waits for the server 4 times here as well. If the
   server SMTP does not check for at least one valid recipient prior to
   accepting the DATA command, the following dialogue would result:

また、クライアントSMTPはここで4回サーバを待っています。 DATAコマンドを受け入れる前にサーバSMTPが少なくとも1人の有効な受取人がないかどうかチェックしないなら、以下の対話は結果として生じるでしょう:

   S: <wait for open connection>
   C: <open connection to server>
   S: 220 innosoft.com SMTP service ready

S: 開いている接続>Cのための<待ち: サーバ>Sとの<のオープンな接続: 220innosoft.com SMTPサービス準備ができています。

Freed                       Standards Track                     [Page 6]

RFC 2920              SMTP for Command Pipelining         September 2000

解放された規格は2000年9月にコマンド連続送信のためにRFC2920SMTPを追跡します[6ページ]。

   C: EHLO dbc.mtview.ca.us
   S: 250-innosoft.com
   S: 250 PIPELINING
   C: MAIL FROM:<mrose@dbc.mtview.ca.us>
   C: RCPT TO:<nsb@thumper.bellcore.com>
   C: RCPT TO:<galvin@tis.com>
   C: DATA
   S: 250 sender <mrose@dbc.mtview.ca.us> OK
   S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
   S: 550 remote mail to <galvin@tis.com> not allowed
   S: 354 enter mail, end with line containing only "."
   C: .
   C: QUIT
   S: 554 no valid recipients
   S: 221 goodbye

C: EHLO dbc.mtview.ca.us S: 250-innosoft.com S: 250 パイプライン処理C: FROM:<mrose@dbc.mtview.ca.us に郵送してください、gt;、C: RCPT TO:<nsb@thumper.bellcore.com 、gt;、C: RCPT TO:<galvin@tis.com 、gt;、C: データS: 250 sender <mrose@dbc.mtview.ca.us 、gt;、OK S: 550のリモートメール to <nsb@thumper.bellore.com 、gt;、Sを許容しません: 550のリモートメール to <galvin@tis.com 、gt;、Sを許容しません: 「354はメール、系列含有だけがある終わりを入れる」、」 C: . C: Sをやめてください: 554 有効な受取人がありませんS: 221さよなら

5.  Security Considerations

5. セキュリティ問題

   This RFC does not discuss security issues and is not believed
   to raise any security issues not endemic in electronic mail
   and present in fully conforming implementations of [RFC-821].

このRFCは安全保障問題について議論しないで、また[RFC-821]の実装を完全に従わせることにおける電子メールの風土病の、そして、現在でないどんな安全保障問題も提起すると信じられていません。

6.  Acknowledgements

6. 承認

   This document is based on the SMTP service extension model
   presented in RFC 1425. Marshall Rose's description of SMTP
   command pipelining in his book "The Internet Message" also
   served as a source of inspiration for this extension.

このドキュメントはRFC1425に提示されたSMTPサービス拡大モデルに基づいています。 また、彼の本「インターネットメッセージ」における、マーシャル・ローズのSMTPコマンド連続送信の記述はこの拡大のためのインスピレーションの源として機能しました。

7.  References

7. 参照

   [RFC-821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
              821, August 1982.

[RFC-821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。

   [RFC-1123] Braden, R., "Requirements for Internet Hosts --
              Application and Support", STD 3, RFC 1123, October, 1989.

[RFC-1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月、1989

   [RFC-1854] Freed, N., "SMTP Service Extension for Command
              Pipelining", RFC 1854, October 1995.

解放された[RFC-1854]、N.、「コマンド連続送信のためのSMTPサービス拡張子」、RFC1854、1995年10月。

   [RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
              Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
              November 1995.

[RFC-1869]Klensin、J.、解放されています、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは拡大を修理します」、STD10、RFC1869、1995年11月。

   [RFC-2197] Freed, N., "SMTP Service Extension for Command
              Pipelining", RFC 2197, September 1997.

解放された[RFC-2197]、N.、「コマンド連続送信のためのSMTPサービス拡張子」、RFC2197、1997年9月。

Freed                       Standards Track                     [Page 7]

RFC 2920              SMTP for Command Pipelining         September 2000

解放された規格は2000年9月にコマンド連続送信のためにRFC2920SMTPを追跡します[7ページ]。

8.  Author's Address

8. 作者のアドレス

   Ned Freed
   Innosoft International, Inc.
   1050 Lakes Drive
   West Covina, CA 91790
   USA

ネッド解放されたInnosoft国際Inc.1050Lakesはウエストコビナ、カリフォルニア91790米国を運転します。

   Phone: +1 626 919 3600
   Fax:   +1 626 919 361
   EMail: ned.freed@innosoft.com

以下に電話をしてください。 +1 626 919、3600Fax: +1 626 919 361はメールされます: ned.freed@innosoft.com

   This document is a product of work done by the Internet Engineering
   Task Force Working Group on Messaging Extensions, Alan Cargille,
   chair.

このドキュメントはMessaging Extensionsでインターネット・エンジニアリング・タスク・フォース作業部会によって行われた仕事の成果です、アランCargille、いす。

Freed                       Standards Track                     [Page 8]

RFC 2920              SMTP for Command Pipelining         September 2000

解放された規格は2000年9月にコマンド連続送信のためにRFC2920SMTPを追跡します[8ページ]。

9.  Full Copyright Statement

9. 完全な著作権宣言文

   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機能のための基金は現在、インターネット協会によって提供されます。

Freed                       Standards Track                     [Page 9]

解放された標準化過程[9ページ]