RFC2197 日本語訳

Network Working Group                                       N. Freed
Request for Comments: 2197                                  Innosoft
Obsoletes: 1854                                       September 1997
Category: Standards Track

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

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

1.  Abstract

1. 要約

   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性能をかなり向上させることができます。

   The present document is an updated version of RFC 1854 [3].  Only
   textual and editorial changes have been made; the protocol has not
   changed in any way.

現在のドキュメントはRFC1854[3]のアップデートされたバージョンです。 原文の、そして、編集の変更だけが行われました。 プロトコルは何らかの方法で変化していません。

2.  Introduction

2. 序論

   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 [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サーバーは適切にコマンド連続送信を扱うことができません。 配布しているサーバで存在するのが知られている欠点は:

Freed                       Standards Track                     [Page 1]

RFC 2197                 SMTP Service Extension           September 1997

標準化過程[1ページ]RFC2197SMTPサービス拡大1997年9月に、解放されます。

    (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 [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クライアントは、次に、この宣言がないかどうかチェックして、パイプライン処理を使用できます。

2.1.  Requirements notation

2.1. 要件記法

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

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

3.  Framework for the Command Pipelining Extension

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

   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 2197                 SMTP Service Extension           September 1997

標準化過程[2ページ]RFC2197SMTPサービス拡大1997年9月に、解放されます。

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

4.  The Pipelining Service Extension

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

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

4.1.  Client use of pipelining

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

パイプライン処理を使うクライアントSMTP実装はグループにおける各コマンドに関連しているすべての状態をチェックしなければなりません。 例えば、RCPT TO受取人アドレスのいずれも受け入れられなかったなら、クライアントはそうしなければなりません。

Freed                       Standards Track                     [Page 3]

RFC 2197                 SMTP Service Extension           September 1997

標準化過程[3ページ]RFC2197SMTPサービス拡大1997年9月に、解放されます。

   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.

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

4.2.  Server support of pipelining

4.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コマンドへの応答を保存するのを選びます。

Freed                       Standards Track                     [Page 4]

RFC 2197                 SMTP Service Extension           September 1997

標準化過程[4ページ]RFC2197SMTPサービス拡大1997年9月に、解放されます。

    (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は応答がどんなコマンドに合っているかをそれとなくか明らかに示す応答テキストを発行します。

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

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

5.  Examples

5. 例

   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さよなら

Freed                       Standards Track                     [Page 5]

RFC 2197                 SMTP Service Extension           September 1997

標準化過程[5ページ]RFC2197SMTPサービス拡大1997年9月に、解放されます。

   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: 354 enter mail, end with line containing only "."
    ...
   C: .
   C: QUIT
   S: 250 message sent
   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:<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さよなら

Freed                       Standards Track                     [Page 6]

RFC 2197                 SMTP Service Extension           September 1997

標準化過程[6ページ]RFC2197SMTPサービス拡大1997年9月に、解放されます。

   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: .
   C: QUIT
   S: 554 no valid recipients
   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を許容しません: 「354はメール、系列含有だけがある終わりを入れる」、」 C: . C: Sをやめてください: 554 有効な受取人がありませんS: 221さよなら

6.  Security Considerations

6. セキュリティ問題

   This document 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].

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

7.  Acknowledgements

7. 承認

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

8.  References

8. 参照

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

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

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

Klensin(J.)が解放した[2]とN.とローズとM.とStefferud、E.とD.クロッカー、「SMTPサービス拡張子」、RFC1869、1995年11月。

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

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

Freed                       Standards Track                     [Page 7]

RFC 2197                 SMTP Service Extension           September 1997

標準化過程[7ページ]RFC2197SMTPサービス拡大1997年9月に、解放されます。

   [4]  Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", RFC 2119, March 1997.

[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。

9.  Author's Address

9. 作者のアドレス

   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 3614
   EMail: ned.freed@innosoft.com

以下に電話をしてください。 +1 626 919、3600Fax: +1 3614年の626 919メール: 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]

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