RFC1854 日本語訳

Network Working Group                                           N. Freed
Request For Comments: 1854                  Innosoft International, Inc.
Category: Standards Track                          A. Cargille, WG Chair
                                                            October 1995

ネットワークワーキンググループN.はコメントを求める要求を解放しました: 1854年のInnosoftの国際Inc.カテゴリ: 標準化過程A.Cargille、WG議長1995年10月

                         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)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This memo defines an extension to the SMTP service whereby a server
   can indicate the extent of its ability to accept multiple commands in
   a single TCP send operation. Using a single TCP send operation for
   multiple commands can improve SMTP performance significantly.

このメモはサーバがTCPが操作を送るシングルにおける複数のコマンドを受け入れる性能の範囲を示すことができるSMTPサービスと拡大を定義します。 複数のコマンドにTCPが操作を送るシングルを使用するのはSMTP性能をかなり向上させることができます。

Introduction

序論

   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は広さと強壮に配布されますが、それにもかかわらず、ある拡大は有用であることが分かるかもしれません。 特に、インターネットの多くの地域が高い潜在ネットワークリンクを利用します。

   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の本質的な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 [1] 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仕様[1]は、SMTPサーバーがこれをサポートしなければならないと明らかに述べませんでした。 その結果、重要な数のインターネットSMTPサーバーは適切にコマンド連続送信を扱うことができません。 配布しているサーバで存在するのが知られている欠点は:

 (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

(1) SMTP対話の途中での接続移管とバッファ水洗。 入って来るSMTP接続のためのサーバプロセスの作成は役に立って、明白で、無害な実装のテクニックです。 しかしながら、いくつかのSMTPサーバーがプロセス分岐と接続移管を延期します。

Freed & Cargille            Standards Track                     [Page 1]

RFC 1854                    SMTP Pipelining                 October 1995

解放されるのとCargille規格はSMTPパイプライン処理1995年10月にRFC1854を追跡します[1ページ]。

       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.

ある中間的になりまで、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 [2] 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サービスと拡大を定義するために[2]で説明されたメカニズムを使用します。 サーバが、それ自体がそれを扱うことができると宣言するときだけ、SMTPクライアントは、次に、この宣言がないかどうかチェックして、パイプライン処理を使用できます。

1.  Framework for the Command Pipelining Extension

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

   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です。

    (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の動きに影響するかを指定します。

Freed & Cargille            Standards Track                     [Page 2]

RFC 1854                    SMTP Pipelining                 October 1995

解放されるのとCargille規格はSMTPパイプライン処理1995年10月にRFC1854を追跡します[2ページ]。

2.  The Pipelining Service Extension

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

   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コマンド連続送信を収容できるのを示しました。

2.1.  Client use of pipelining

2.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, the RSET/MAIL FROM sequence
   necessary 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
   was accepted the client SMTP should send a single dot.

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

すぐ領収書にサーバ応答を処理さえして、クライアントSMTP実装は、「非-妨げ」ファッションで作動するのを選ぶかもしれません。

Freed & Cargille            Standards Track                     [Page 3]

RFC 1854                    SMTP Pipelining                 October 1995

解放されるのとCargille規格はSMTPパイプライン処理1995年10月にRFC1854を追跡します[3ページ]。

   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に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つ以上の系列を必要とします。

2.2.  Server support of pipelining

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

   A server SMTP implementation that offers the pipelining extension:

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

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

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

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

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

    (3)   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コマンドへの積極的な応答を発行して、次に空のメッセージを受け取った後に、(3)は全くどんなメッセージもだれにも送ってはいけません。

    (4)   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.

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

    (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)は認識されていないコマンドへの応答をバッファリングしてはいけません。

    (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)   SHOULD issue response text that indicates, either
          implicitly or explicitly, what command the response
          matches.

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

Freed & Cargille            Standards Track                     [Page 4]

RFC 1854                    SMTP Pipelining                 October 1995

解放されるのとCargille規格はSMTPパイプライン処理1995年10月にRFC1854を追跡します[4ページ]。

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

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

3.  Examples

3. 例

   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
   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: 開いている接続>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:<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

Freed & Cargille            Standards Track                     [Page 5]

RFC 1854                    SMTP Pipelining                 October 1995

解放されるのとCargille規格はSMTPパイプライン処理1995年10月にRFC1854を追跡します[5ページ]。

   S: 354 enter mail, end with line containing only "."
    ...
   C: .
   C: QUIT
   S: 250 message sent
   S: 221 goodbye

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
   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: .

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を許容しません: 「354はメール、系列含有だけがある終わりを入れる」、」 C: .

Freed & Cargille            Standards Track                     [Page 6]

RFC 1854                    SMTP Pipelining                 October 1995

解放されるのとCargille規格はSMTPパイプライン処理1995年10月にRFC1854を追跡します[6ページ]。

   C: QUIT
   S: 554 no valid recipients
   S: 221 goodbye

C: Sをやめてください: 554 有効な受取人がありませんS: 221さよなら

4.  Security Considerations

4. セキュリティ問題

   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 [1].

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

5.  Acknowledgements

5. 承認

   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コマンド連続送信の記述はこの拡大のためのインスピレーションの源として機能しました。

6.  References

6. 参照

   [1]  Postel, J., "Simple Mail Transfer Protocol", STD 10
        RFC 821, USC/Information Sciences Institute, August
        1982.

[1] ポステル、J.、「簡単なメール転送プロトコル」、STD10RFC821、科学が1982年8月に設けるUSC/情報。

   [2]  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.)が解放した[2]、Inc.、ネットワークマネージメントに相談するRFC1651、MCI、Innosoft、ドーヴァーが無能にするN.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPサービス拡張子」がInc.を関連づけます、シリコングラフィックス、1994年7月。

7.  Author's Address

7. 作者のアドレス

   Ned Freed
   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

Freed & Cargille            Standards Track                     [Page 7]

解放されるのとCargille標準化過程[7ページ]