RFC2033 日本語訳

Network Working Group                                           J. Myers
Request for Comments: 2033                               Carnegie Mellon
Category: Informational                                     October 1996

コメントを求めるワーキンググループJ.マイアーズの要求をネットワークでつないでください: 2033年のカーネギーメロンCategory: 情報の1996年10月

                      Local Mail Transfer Protocol

ローカルのメール転送プロトコル

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

1.  Abstract

1. 要約

   SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a
   mechanism for transferring mail reliably and efficiently.  The design
   of the SMTP protocol effectively requires the server to manage a mail
   delivery queue.

SMTP[SMTP][HOST-REQ]とそのサービス拡大[ESMTP]は確かに効率的にメールを移すのにメカニズムを提供します。 事実上、SMTPプロトコルのデザインは、郵便配達待ち行列を管理するためにサーバを必要とします。

   In some limited circumstances, outside the area of mail exchange
   between independent hosts on public networks, it is desirable to
   implement a system where a mail receiver does not manage a queue.
   This document describes the LMTP protocol for transporting mail into
   such systems.

いくつかの限られた事情では、公衆通信回線の独立しているホストの間のメール交換の領域の外では、メール受信機が待ち行列を管理しないシステムを導入するのは望ましいです。 このドキュメントは、そのようなシステムにメールを輸送するためにLMTPプロトコルについて説明します。

   Although LMTP is an alternative protocol to ESMTP, it uses (with a
   few changes) the syntax and semantics of ESMTP.  This design permits
   LMTP to utilize the extensions defined for ESMTP.  LMTP should be
   used only by specific prior arrangement and configuration, and it
   MUST NOT be used on TCP port 25.

LMTPはESMTPへの代替のプロトコルですが、それはESMTPの構文と意味論を使用します(いくつかの変化で)。 このデザインは、LMTPがESMTPのために定義された拡大を利用することを許可します。 特定の先のアレンジメントと構成だけでLMTPを使用するべきです、そして、TCPポート25の上でそれは使用してはいけません。

Table of Contents

目次

   1.   Abstract ................................................    1
   2.   Conventions Used in this Document .......................    2
   3.   Introduction and Overview ...............................    2
   4.   The LMTP protocol .......................................    3
   4.1. The LHLO, HELO and EHLO commands ........................    4
   4.2. The DATA command ........................................    4
   4.3. The BDAT command ........................................    5
   5.   Implementation requirements .............................    6
   6.   Acknowledgments .........................................    6
   7.   References ..............................................    7
   8.   Security Considerations .................................    7
   9.   Author's Address ........................................    7

1. 要約… 1 2. このDocumentのコンベンションUsed… 2 3. 序論と概要… 2 4. LMTPは議定書を作ります… 3 4.1. LHLO、HELO、およびEHLOコマンド… 4 4.2. DATAは命令します… 4 4.3. BDATは命令します… 5 5. 実装要件… 6 6. 承認… 6 7. 参照… 7 8. セキュリティ問題… 7 9. 作者のアドレス… 7

Myers                        Informational                      [Page 1]

RFC 2033                          LMTP                      October 1996

[1ページ]RFC2033LMTP1996年10月の情報のマイアーズ

2.  Conventions Used in this Document

2. このDocumentのコンベンションUsed

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。

3.  Introduction and Overview

3. 序論と概要

   The design of the SMTP protocol effectively requires the server to
   manage a mail delivery queue.  This is because a single mail
   transaction may specify multiple recipients and the final "." of the
   DATA command may return only one reply code, to indicate the status
   of the entire transaction.  If, for example, a server is given a
   transaction for two recipients, delivery to the first succeeds, and
   delivery to the second encounters a temporary failure condition,
   there is no mechanism to inform the client of the situation.  The
   server must queue the message and later attempt to deliver it to the
   second recipient.

事実上、SMTPプロトコルのデザインは、郵便配達待ち行列を管理するためにサーバを必要とします。 「これはただ一つのメールトランザクションが複数の受取人と決勝を指定するかもしれないからです。」. 」 データでは、コマンドは、全体のトランザクションの状態を示すために1つの回答コードだけを返すかもしれません。 例えば、2人の受取人のためにトランザクションをサーバに与えて、1日への配送が成功して、2番目への配送が一時障害状態に遭遇するなら、状況についてクライアントに知らせるために、メカニズムは全くありません。 サーバは、メッセージを列に並ばせて、後で2番目の受取人にそれを提供するのを試みなければなりません。

   This queuing requirement is beneficial in the situation for which
   SMTP was originally designed: store-and-forward relay of mail between
   networked hosts.  In some limited situations, it is desirable to have
   a server which does not manage a queue, instead relying on the client
   to perform queue management.  As an example, consider a hypothetical
   host with a mail system designed as follows:

この列を作り要件はSMTPが元々設計された状況で有益です: ネットワークでつながれたホストの間にメールのリレーを保存して、送ってください。 いくつかの限られた状況で、待ち行列を管理しないサーバを持っているのは望ましいです、待ち行列管理を実行するために代わりにクライアントに頼って。 例として、メールシステムが設計されている仮定しているホストは以下の通りであると考えてください:

                    TCP port 25 +-----------------+
         ---------------------->|                 |  #########
                                |      Queue      |<># Mail  #
         TCP port 25            |     Manager     |  # Queue #
         <----------------------|                 |  #########
                                +-----------------+
                            Local *  ^ Local    * Local
                              IPC *  | IPC      * IPC
                                  *  |          *
                                  *  |          *
                                  *  |          *
                                  V  |          V
                  Non-SMTP    +----------+     +----------+
                  Protocol    | Gateway  |     |  Local   |  #########
              <==============>| Delivery |     | Delivery |>># Mail  #
                              |  Agent   |     |  Agent   |  # Spool #
                              +----------+     +----------+  #########

TCPポート25+-----------------+ ---------------------->|、| ######### | 待ち行列|<># #TCPポート25を郵送してください。| マネージャ| # 待ち行列#<。----------------------| | ######### +-----------------+ Local * ^ Local * Local IPC * | IPC*IPC*| * * | * * | * V| V非SMTP+----------+ +----------+ プロトコル| ゲートウェイ| | ローカル| ######### <=======>| 配送| | 配送|>># #、を郵送してください。| エージェント| | エージェント| # スプール#+----------+ +----------+ #########

   The host's mail system has three independent, communicating
   subsystems.  The first is a queue manager, which acts as a

サブシステムを伝えて、ホストのメールシステムには3独立者がいます。1番目は待ち行列管理プログラムです。(その待ち行列管理プログラムはaとして務めます)。

Myers                        Informational                      [Page 2]

RFC 2033                          LMTP                      October 1996

[2ページ]RFC2033LMTP1996年10月の情報のマイアーズ

   traditional SMTP agent, transferring messages to and from other hosts
   over TCP and managing a mail queue in persistent storage.  The other
   two are agents which handle delivery for addresses in domains for
   which the host takes responsibility.  One agent performs gatewaying
   to and from some other mail system.  The other agent delivers the
   message into a persistent mail spool.

ホストとTCPの上の他のホストからメッセージを移して、永続的なストレージでメール待ち行列を管理する伝統的なSMTPエージェント。 他の2はエージェントです(ホストが責任を取るドメインでアドレスのための配送を扱います)。 1人のエージェントが、システムとある他のメールシステムからgatewayingしながら、働きます。 もう片方のエージェントは永続的なメールスプールにメッセージを提供します。

   It would be desirable to use SMTP over a local inter-process
   communication channel to transfer messages from the queue manager to
   the delivery agents.  It would, however, significantly increase the
   complexity of the delivery agents to require them to manage their own
   mail queues.

待ち行列管理プログラムから新聞販売店までメッセージを移すのにローカルの相互プロセス通信チャネルの上でSMTPを使用するのは望ましいでしょう。 しかしながら、それは、それら自身のメール待ち行列を管理するのが必要であるように新聞販売店の複雑さをかなり増強するでしょう。

   The common practice of invoking a delivery agent with the envelope
   address(es) as command-line arguments, then having the delivery agent
   communicate status with an exit code has three serious problems: the
   agent can only return one exit code to be applied to all recipients,
   it is difficult to extend the interface to deal with ESMTP extensions
   such as DSN [DSN] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES], and
   exits performed by system libraries due to temporary conditions
   frequently get interpreted as permanent errors.

コマンドライン議論として封筒アドレス(es)で新聞販売店を呼び出して、次に、新聞販売店に出口コードと状態を伝えさせる一般的な習慣には、3つの深刻な問題があります: エージェントはすべての受取人に適用されるために1つの出口コードしか返すことができません、そして、DSN[DSN]やENHANCEDSTATUSCODES[ENHANCEDSTATUSCODES]などのESMTP拡張子に対処するためにインタフェースを広げるのが難しく、一時的な病態のためシステムライブラリによって実行された出口は永続エラーとして頻繁に解釈されます。

   The LMTP protocol causes the server to return, after the final "." of
   the DATA command, one reply for each recipient.  Therefore, if the
   queue manager is configured to use LMTP instead of SMTP when
   transferring messages to the delivery agents, then the delivery
   agents may attempt delivery to each recipient after the final "." and
   individually report the status for each recipient.  Connections which
   should use the LMTP protocol are drawn in the diagram above using
   asterisks.

「サーバはLMTPプロトコルで戻ります、決勝の後に」。. 」 データコマンドでは、1つは各受取人を代わって答えます。 「したがって、待ち行列管理プログラムがメッセージを新聞販売店に移すとき、SMTPの代わりにLMTPを使用するために構成されるなら、新聞販売店は決勝の後に各受取人に配送を試みるかもしれません」。. 」 各受取人のために個別に状態を報告してください。 アスタリスクを使用する上にLMTPプロトコルを使用するべきであるコネクションズがダイヤグラムで描かれます。

   Note that it is not beneficial to use the LMTP protocol when
   transferring messages to the queue manager, either from the network
   or from a delivery agent.  The queue manager does implement a mail
   queue, so it may store the message and take responsibility for later
   delivering it.

待ち行列管理プログラムか、ネットワークか新聞販売店からメッセージを移すときにはLMTPプロトコルを使用するのが有益でないことに注意してください。 待ち行列管理プログラムがメール待ち行列を実装するので、それは、メッセージを保存して、後でそれを提供することへの責任を取るかもしれません。

4.  The LMTP protocol

4. LMTPプロトコル

   The LMTP protocol is identical to the SMTP protocol SMTP [SMTP]
   [HOST-REQ] with its service extensions [ESMTP], except as modified by
   this document.

LMTPプロトコルはサービス拡大[ESMTP]でSMTPプロトコルSMTP[SMTP][HOST-REQ]と同じです、このドキュメントによって変更されるのを除いて。

   A "successful" RCPT command is defined as an RCPT command which
   returns a Positive Completion reply code.

「うまくいっている」RCPTコマンドはPositive Completion回答コードを返すRCPTコマンドと定義されます。

   A "Positive Completion reply code" is defined in Appendix E of STD
   10, RFC 821 [SMTP] as a reply code which "2" as the first digit.

「上向きのCompletion回答コード」はSTD10のAppendix Eで定義されて、回答としてのRFC821[SMTP]はどの「最初のケタとしての2インチ」をコード化するか。

Myers                        Informational                      [Page 3]

RFC 2033                          LMTP                      October 1996

[3ページ]RFC2033LMTP1996年10月の情報のマイアーズ

4.1.  The LHLO, HELO and EHLO commands

4.1. LHLO、HELO、およびEHLOコマンド

   The HELO and EHLO commands of ESMTP are replaced by the LHLO command.
   This permits a misconfiguration where both parties are not using the
   same protocol to be detected.

ESMTPのHELOとEHLOコマンドをLHLOコマンドに取り替えます。 これは、双方が同じプロトコルを使用していないmisconfigurationが検出されることを許可します。

   The LHLO command has identical semantics to the EHLO command of ESMTP
   [ESMTP].

LHLOコマンドはESMTP[ESMTP]のEHLOコマンドに同じ意味論を持っています。

   The HELO and EHLO commands of ESMTP are not present in LMTP.  A LMTP
   server MUST NOT return a Postive Completion reply code to these
   commands.  The 500 reply code is recommended.

ESMTPのHELOとEHLOコマンドはLMTPに存在していません。 LMTPサーバはPostive Completion回答コードをこれらのコマンドに返してはいけません。 500回答コードはお勧めです。

4.2.  The DATA command

4.2. DATAコマンド

   In the LMTP protocol, there is one additional restriction placed on
   the DATA command, and one change to how replies to the final "." are
   sent.

どのようにが決勝に答えるか。「LMTPプロトコルには、追加制限がDATAコマンドに置いて、1つが変化する1つがある、」 . 」 送ります。

   The additional restriction is that when there have been no successful
   RCPT commands in the mail transaction, the DATA command MUST fail
   with a 503 reply code.

追加制限はメールトランザクションにどんなうまくいっているRCPTコマンドもなかったとき、503回答コードに応じてDATAコマンドが失敗しなければならないということです。

   The change is that after the final ".", the server returns one reply
   for each previously successful RCPT command in the mail transaction,
   in the order that the RCPT commands were issued.  Even if there were
   multiple successful RCPT commands giving the same forward-path, there
   must be one reply for each successful RCPT command.

「変化は決勝の後のそれです」、」、サーバリターン1は、それぞれの以前にうまくいっているRCPTコマンドのためにメールトランザクション、オーダーでRCPTコマンドが発行されたと返答します。 同じフォワードパスを与える複数のうまくいっているRCPTコマンドがあったとしても、それぞれのうまくいっているRCPTコマンドあたり1つの回答があるに違いありません。

   When one of these replies to the final "." is a Positive Completion
   reply, the server is accepting responsibility for delivering or
   relying the message to the corresponding recipient.  It must take
   this responsibility seriously, i.e., it MUST NOT lose the message for
   frivolous reasons, e.g., because the host later crashes or because of
   a predictable resource shortage.

「決勝に関するこれらの回答の1つであるときに」。. 」 積極的な完成は回答ですサーバが配送することへの責任を引き受けているか、または信用が対応する受取人へのメッセージを引き受けていること。 それは真剣にこの責任を受け止めなければなりません、すなわち、ホストが後でダウンするためか例えば、軽薄な理由か、予測できるリソース不足のでメッセージを失ってはいけません。

   A multiline reply is still considered a single reply and corresponds
   to a single RCPT command.

マルチライン回答は、ただ一つの回答であるとまだ考えられていて、ただ一つのRCPTコマンドに対応しています。

   EXAMPLE:

例:

   S: 220 foo.edu LMTP server ready
   C: LHLO foo.edu
   S: 250-foo.edu
   S: 250-PIPELINING
   S: 250 SIZE
   C: MAIL FROM:<chris@bar.com>
   S: 250 OK

S: 220 foo.edu LMTPのサーバ持ち合わせのC: LHLO foo.edu S: 250-foo.edu S: 250パイプライン処理S: 250 サイズC: FROM:<chris@bar.com に郵送してください、gt;、S: 250 OK

Myers                        Informational                      [Page 4]

RFC 2033                          LMTP                      October 1996

[4ページ]RFC2033LMTP1996年10月の情報のマイアーズ

   C: RCPT TO:<pat@foo.edu>
   S: 250 OK
   C: RCPT TO:<jones@foo.edu>
   S: 550 No such user here
   C: RCPT TO:<green@foo.edu>
   S: 250 OK
   C: DATA
   S: 354 Start mail input; end with <CRLF>.<CRLF>
   C: Blah blah blah...
   C: ...etc. etc. etc.
   C: .
   S: 250 OK
   S: 452 <green@foo.edu> is temporarily over quota
   C: QUIT
   S: 221 foo.edu closing connection

C: RCPT TO:<pat@foo.edu 、gt;、S: 250 OK C: RCPT TO:<jones@foo.edu 、gt;、S: ここのそのような550人のユーザでない、C: RCPT TO:<green@foo.edu 、gt;、S: 250 OK C: データS: 354 メール入力を始めてください。 <CRLF><CRLF>Cで、終わってください: 何のかの… C: ...などなどなど C: . S: 250 OK S: 452 <green@foo.edu 、gt;、一時、割当てCの上あります: Sをやめてください: 221 接続を終えるfoo.edu

NOTE: in the above example, the domain names of both the client and
   server are identical.  This is because in the example the client and
   server are different subsystems of the same mail domain.

以下に注意してください。 上記の例では、クライアントとサーバの両方のドメイン名は同じです。 これはクライアントとサーバが例の同じメール・ドメインの異なったサブシステムであるからです。

4.3.  The BDAT command

4.3. BDATコマンド

   If the server supports the ESMTP CHUNKING extension [BINARYMIME], a
   BDAT command containing the LAST parameter returns one reply for each
   previously successful RCPT command in the mail transaction, in the
   order that the RCPT commands were issued.  Even if there were
   multiple successful RCPT commands giving the same forward-path, there
   must be one reply for each successful RCPT command.  If there were no
   previously successful RCPT commands in the mail transaction, then the
   BDAT LAST command returns zero replies.

サーバが、ESMTP CHUNKINGが拡大[BINARYMIME]であるとサポートするなら、LASTパラメタを含むBDATコマンドはメールトランザクションにおけるそれぞれの以前にうまくいっているRCPTコマンドあたり1つの回答を返します、RCPTコマンドが発行されたオーダーで。 同じフォワードパスを与える複数のうまくいっているRCPTコマンドがあったとしても、それぞれのうまくいっているRCPTコマンドあたり1つの回答があるに違いありません。 メールトランザクションにどんな以前にうまくいっているRCPTコマンドもなかったなら、BDAT LASTコマンドは回答を全く返しません。

   When one of these replies to the BDAT LAST command is a Positive
   Completion reply, the server is accepting responsibility for
   delivering or relaying the message to the corresponding recipient.
   It must take this responsibility seriously, i.e., it MUST NOT lose
   the message for frivolous reasons, e.g., because the host later
   crashes or because of a predictable resource shortage.

BDAT LASTコマンドに関するこれらの回答の1つがPositive Completion回答であるときに、サーバは対応する受取人にメッセージを提供するか、またはリレーすることへの責任を引き受けています。 それは真剣にこの責任を受け止めなければなりません、すなわち、ホストが後でダウンするためか例えば、軽薄な理由か、予測できるリソース不足のでメッセージを失ってはいけません。

   A multiline reply is still considered a single reply and corresponds
   to a single RCPT command.

マルチライン回答は、ただ一つの回答であるとまだ考えられていて、ただ一つのRCPTコマンドに対応しています。

   The behavior of BDAT commands without the LAST parameter is not
   changed; they still return exactly one reply.

LASTパラメタのないBDATコマンドの振舞いは変えられません。 彼らはまだまさに1つの回答を返しています。

Myers                        Informational                      [Page 5]

RFC 2033                          LMTP                      October 1996

[5ページ]RFC2033LMTP1996年10月の情報のマイアーズ

5.  Implementation requirements

5. 実装要件

   As LMTP is a different protocol than SMTP, it MUST NOT be used on the
   TCP service port 25.

LMTPがSMTPより異なったプロトコルであるので、それはTCPサービスポート25で使用されているはずがありません。

   A server implementation MUST implement the PIPELINING [PIPELINING]
   and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions.  A
   server implementation SHOULD implement the 8BITMIME [8BITMIME]
   extension.

サーバ実装は、PIPELINING[PIPELINING]とENHANCEDSTATUSCODES[ENHANCEDSTATUSCODES]がESMTP拡張子であると実装しなければなりません。 SHOULDが8BITMIME[8BITMIME]拡張子を実装するサーバ実装。

   Use of LMTP can aggravate the situation described in [DUP-MSGS].  To
   avoid this synchronization problem, the following requirements are
   made of implementations:

LMTPの使用は[DUP-MSGS]で説明された状況をいらいらさせることができます。 この同期問題を避けるために、以下の要件は実装で作られています:

   A server implementation which is capable of quickly accepting
   responsibility for delivering or relaying a message to multiple
   recipients and which is capable of sending any necessary notification
   messages SHOULD NOT implement the LMTP protocol.

配送することへのすぐに受け入れている責任か複数の受取人に伝言を伝えることができて、SHOULD NOTが実装するどんな必要な通知メッセージにもLMTPプロトコルを送ることができるサーバ実装。

   The LMTP protocol SHOULD NOT be used over wide area networks.

LMTPはSHOULD NOTについて議定書の中で述べます。広域ネットワークの上で使用されます。

   The server SHOULD send each reply as soon as possible.  If it is
   going to spend a nontrivial amount of time handling delivery for the
   next recipient, it SHOULD flush any outgoing LMTP buffer, so the
   reply may be quickly received by the client.

サーバSHOULDはできるだけ早く、各回答を送ります。 それが重要な時間取り扱い配送を次の受取人に費やして、どんな出発しているLMTPもバッファリングするSHOULD水洗であるので、回答はクライアントによってすぐに受け取られるかもしれません。

   The client SHOULD process the replies as they come in, instead of
   waiting for all of the replies to arrive before processing any of
   them.  If the connection closes after replies for some, but not all,
   recipients have arrived, the client MUST process the replies that
   arrived and treat the rest as temporary failures.

入るとき、クライアントSHOULDは回答を処理します、それらのどれかを処理する前に回答のすべてが到着するのを待つことの代わりに。 受取人ではなく、いくつかのための回答が到着した後に接続が閉じるなら、クライアントは、到着した回答を処理して、一時障害として残りを扱わなければなりません。

6.  Acknowledgments

6. 承認

   This work is a refinement of the MULT extension, which was invented
   by Jeff Michaud and was used in implementing gateways to the Mail-11
   mail system.

この仕事はMULT拡張子の気品です。(それは、ジェフ・ミショーによって発明されて、メール-11メールシステムへのゲートウェイを実装する際に使用されました)。

   Many thanks to Matt Thomas for assisting me in understanding the
   semantics of the Mail-11 MULT extension.

メール-11MULT拡張子の意味論を理解しているのにマット・トーマスに助けてくださいといってくださってありがとうございますこと私を。

Myers                        Informational                      [Page 6]

RFC 2033                          LMTP                      October 1996

[6ページ]RFC2033LMTP1996年10月の情報のマイアーズ

7.  References

7. 参照

   [8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-MIME
       transport", RFC 1652, July 1994.

[8BITMIME] 1994年7月のet Klensin、J.、アル、「8ビットのMIME輸送のためのSMTP Service Extension」RFC1652。

   [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission
       of Large and Binary MIME Messages", RFC 1830, August 1995.

[BINARYMIME]ボードルイ、G.、「大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子」、RFC1830、1995年8月。

   [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for
       Delivery Status Notifications", RFC 1894, January 1996.

[DSN] ムーア、K.、ボードルイ、G.、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC1894、1996年1月。

   [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047,
       February 1988.

[DUP-MSGS]ヤマウズラと、C.と、「写しメッセージとSMTP」、1988年2月のRFC1047。

   [ENHANCEDSTATUSCODES] Freed, N., "SMTP Service Extension for
       Returning Enhanced Error Codes", RFC 2034, October 1996.

解放された[ENHANCEDSTATUSCODES]、N.、「戻るためのSMTPサービス拡張子はエラーコードを高めた」RFC2034、1996年10月。

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

[ESMTP] J. ローズ、M.、Stefferud、E.、クロッカー、C.、Klensin、N.、解放されて、「SMTPサービス拡張子」、RFC1869、11月1995日

   [HOST-REQ] Braden, R., "Requirements for Internet hosts - application
       and support", STD 3, RFC 1123 section 5, October 1989.

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

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

[パイプライン処理] フリード、N.、Cargille、A、「コマンド連続送信のためのSMTPサービス拡張子」、RFC1854、1995年10月。

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

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

   There are no known security issues with the issues in this memo.

このメモによる問題の安全保障問題は知られていません。

9.  Author's Address

9. 作者のアドレス

   John G. Myers
   Carnegie-Mellon University
   5000 Forbes Ave.
   Pittsburgh PA, 15213-3890

ジョンG.マイアーズカーネギーメロン大学5000フォーブズAve。 ピッツバーグPA、15213-3890

   EMail: jgm+@cmu.edu

メール: jgm+@cmu.edu

Myers                        Informational                      [Page 7]

マイアーズ情報です。[7ページ]