RFC1985 日本語訳

Network Working Group                                       J. De Winter
Request for Comments: 1985                     Wildbear Consulting, Inc.
Category: Standards Track                                    August 1996

コメントを求めるワーキンググループJ.De冬の要求をネットワークでつないでください: 1985年のWildbearコンサルティングInc.カテゴリ: 標準化過程1996年8月

                         SMTP Service Extension
                   for Remote Message Queue Starting

リモートメッセージキュー始めのための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
   start the processing of its queues for messages to go to a given
   host.  This extension is meant to be used in startup conditions as
   well as for mail nodes that have transient connections to their
   service providers.

このメモはSMTPクライアントとサーバが与えられたホストに行くメッセージのための待ち行列の処理を始める機会をサーバに与えるために相互作用するかもしれないSMTPサービスと拡大を定義します。 始動状態と彼らのサービスプロバイダーには一時的な接続があるメールノードのために、この拡大は使用されることになっています。

1.  Introduction

1. 序論

   The TURN command was a valid attempt to address the problem of having
   to start the processing for the mail queue on a remote machine.
   However, the TURN command presents a large security loophole.  As
   there is no verification of the remote host name, the TURN command
   could be used by a rogue system to download the mail for a site other
   than itself.

TURNコマンドは始まらなければならないという問題がリモートマシンにおけるメール待ち行列のための処理であると扱う有効な試みでした。 しかしながら、TURNコマンドは大きいセキュリティーの抜け道を提示します。 リモートホスト名の検証が全くなくてTURNコマンドは凶暴なシステムによって使用されて、それ自体以外のサイトのためのメールをダウンロードできました。

   Therefore, this memo introduces the ETRN command.  This command uses
   the mechanism defined in [4] to define extensions to the SMTP service
   whereby a client ("sender-SMTP") may request that the server
   ("receiver-SMTP") start the processing of its mail queues for
   messages that are waiting at the server for the client machine.  If
   any messages are at the server for the client, then the server should
   create a new SMTP session and send the messages at that time.

したがって、このメモはETRNコマンドを紹介します。 このコマンドはサーバでクライアントマシンを待っているメッセージにクライアント(「送付者-SMTP」)が、サーバ(「受信機-SMTP」)がメール待ち行列の処理を始めるよう要求するかもしれないSMTPサービスと拡大を定義するために[4]で定義されたメカニズムを使用します。 クライアントのためのサーバに何かメッセージがあるなら、サーバは、新しいSMTPセッションを作成して、その時、メッセージを送るべきです。

De Winter                   Standards Track                     [Page 1]

RFC 1985             SMTP Service Extension - ETRN           August 1996

De冬の標準化過程[1ページ]RFC1985SMTPサービス拡張子--ETRN1996年8月

2.  Framework for the ETRN Extension

2. ETRN拡張子のためのフレームワーク

   The following service extension is therefore defined:

したがって、以下のサービス拡大は定義されます:

   (1) the name of the SMTP service extension is "Remote Queue
   Processing Declaration";

(1) SMTPサービス拡張子の名前は「リモート待ち行列処理宣言」です。

   (2) the EHLO keyword value associated with this extension is "ETRN",
   with no associated parameters;

(2) この拡大に関連しているEHLOキーワード価値は関連パラメタがなければ"ETRN"です。

   (3) one additional verb, ETRN, with a single parameter that
   specifies the name of the client(s) to start processing for;

(3) 1つの追加動詞、処理し始めるためにクライアントの名前を指定するただ一つのパラメタがあるETRN。

   (4) no additional SMTP verbs are defined by this extension.

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

   The remainder of this memo specifies how support for the extension
   affects the behavior of an SMTP client and server.

このメモの残りは拡大のサポートがどうSMTPクライアントとサーバの働きに影響するかを指定します。

3.  The Remote Queue Processing Declaration service extension

3. Remote Queue Processing Declarationサービス拡張子

   To save money, many small companies want to only maintain transient
   connections to their service providers.  In addition, there are some
   situations where the client sites depend on their mail arriving
   quickly, so forcing the queues on the server belonging to their
   service provider may be more desirable than waiting for the retry
   timeout to occur.

お金を貯めるために、多くの小会社が彼らのサービスプロバイダーに一時的な接続を維持するだけでありたいです。 さらに、いくつかの状況がクライアントサイトがすぐ着くそれらのメールによるところにあるので、再試行タイムアウトが起こるのを待つよりそれらのサービスプロバイダーに属すサーバに待ち行列を押しつけるのは望ましいかもしれません。

   Both of these situations could currently be fixed using the TURN
   command defined in [1], if it were not for a large security loophole
   in the TURN command.  As it stands, the TURN command will reverse the
   direction of the SMTP connection and assume that the remote host is
   being honest about what its name is.  The security loophole is that
   there is no documented stipulation for checking the authenticity of
   the remote host name, as given in the HELO or EHLO command.  As such,
   most SMTP and ESMTP implementations do not implement the TURN command
   to avoid this security loophole.

現在[1]で定義されたTURNコマンドを使用することでこれらの状況の両方を修理できるでしょう、TURNコマンドにおける大きいセキュリティーの抜け道がなければ。 立つように、TURNコマンドは、SMTP接続の方向を逆にして、リモートホストが名前が何であるかに関して正直な状態であると仮定するでしょう。 リモートホスト名の信憑性をチェックするための記録された約款が全くHELOかEHLOコマンドで与えるようにないセキュリティーの抜け道があります。 そういうものとして、ほとんどのSMTPとESMTP実装は、TURNがこのセキュリティーの抜け道を避けるコマンドであると実装しません。

   This has been addressed in the design of the ETRN command.  This
   extended turn command was written with the points in the first
   paragraph in mind, yet paying attention to the problems that
   currently exist with the TURN command.  The security loophole is
   avoided by asking the server to start a new connection aimed at the
   specified client.

これはETRNコマンドのデザインで扱われました。 ポイントが第一節にある状態で、この拡張ターンコマンドは念頭に書かれました、まだ現在TURNコマンドで存在する問題に注意を向けていて。 指定されたクライアントを対象にした新しい接続を始めるようにサーバに頼むことによって、セキュリティーの抜け道は避けられます。

   In this manner, the server has a lot more certainty that it is
   talking to the correct SMTP client.  This mechanism can just be seen
   as a more immediate version of the retry queues that appear in most
   SMTP implementations.  In addition, as this command will take a

この様に、サーバには、正しいSMTPクライアントと話しているというずっと多くの確実性があります。 このメカニズムをただほとんどのSMTP実装に現れる再試行待ち行列の、より即座のバージョンと考えることができます。 このコマンドとして、さらに、aを取るために望んでください。

De Winter                   Standards Track                     [Page 2]

RFC 1985             SMTP Service Extension - ETRN           August 1996

De冬の標準化過程[2ページ]RFC1985SMTPサービス拡張子--ETRN1996年8月

   single parameter, the name of the remote host(s) to start the queues
   for, the server can decide whether it wishes to respect the request
   or deny it for any local administrative reasons.

ただ一つのパラメタ、待ち行列を始めるリモートホストの名前、サーバはそれが何かローカルの管理理由で要求を尊敬したいか、またはそれを否定したがっているかどうか決めることができます。

4.  Definitions

4. 定義

   Remote queue processing means that using an SMTP or ESMTP connection,
   the client may request that the server start to process parts of its
   messaging queue.  This processing is performed using the existing
   SMTP infrastructure and will occur at some point after the processing
   is initiated.

リモート待ち行列処理は、SMTPかESMTP接続を使用して、クライアントが、サーバがメッセージング待ち行列の部品を加工処理し始めるよう要求するかもしれないことを意味します。 この処理は、既存のSMTPインフラストラクチャを使用することで実行されて、開始された後に何らかのポイントに起こるでしょう。

      The server host is the node that is responding to the ETRN
      command.

サーバー・ホストはETRNコマンドに応じているノードです。

      The client host is the node that is initiating the ETRN command.

クライアントホストはETRNコマンドを開始しているノードです。

   The remote host name is defined to be a plain-text field that
   specifies a name for the remote host(s).  This remote host name may
   also include an alias for the specified remote host or special
   commands to identify other types of queues.

リモートホスト名は、リモートホストに名前を指定するプレーンテキスト分野になるように定義されます。 また、このリモートホスト名は指定されたリモートホストか他のタイプの待ち行列を特定する特別なコマンドのための別名を含むかもしれません。

5.  The extended ETRN command

5. 拡張ETRNコマンド

   The extended ETRN command is issued by the client host when it wishes
   to start the SMTP queue processing of a given server host.  The
   syntax of this command is as follows:

与えられたサーバー・ホストのSMTP待ち行列処理を始めたがっているとき、拡張ETRNコマンドはクライアントホストによって発行されます。 このコマンドの構文は以下の通りです:

      ETRN [<option character>]<node name><CR><LF>

ETRN[<オプションキャラクタ>]<ノード名><CR><LF>。

   This command may be issued at any time once a session is established,
   as long as there is not a transaction occuring.  Thus, this command
   is illegal between a MAIL FROM: command and the end of the DATA
   commands and responses.

いったんセッションを確立すると、いつでもこのコマンドを発行するかもしれません、トランザクション存在がない限り。 したがって、このコマンドはメールFROM:の間で不法です。 DATAコマンドと応答のコマンドと終わり。

   The specified node name must be a fully qualified domain name for the
   node, which may refer to a CNAME or MX pointer in the DNS.  If an
   alias is used for the node, multiple ETRN commands may be needed to
   start the processing for the node as it may be listed at the remote
   site under multiple names.  This can also be addressed using the
   options discussed in section 5.3.

指定されたノード名はノードのための完全修飾ドメイン名でなければなりません。(それは、DNSのCNAMEかMX指針について言及するかもしれません)。 別名がノードに使用されるなら、複数のETRNコマンドが、それが複数の名前の下のリモートサイトに記載されているときノードのための処理を始めるのに必要であるかもしれません。 また、セクション5.3で議論したオプションを使用することでこれを扱うことができます。

   The option character under normal circumstances is not used.

オプションキャラクタは通常の状況下で使用されていません。

De Winter                   Standards Track                     [Page 3]

RFC 1985             SMTP Service Extension - ETRN           August 1996

De冬の標準化過程[3ページ]RFC1985SMTPサービス拡張子--ETRN1996年8月

5.1  Server action on receipt of the extended ETRN command

5.1 拡張ETRNコマンドを受け取り次第サーバ動作

   When the server host receives the ETRN command, it should have a look
   at the node name that is specified in the command and make a local
   decision if it should honour the request.  If not, the appropriate
   error codes should be returned to the client.

サーバー・ホストがETRNコマンドを受け取るとき、それは、要求を尊敬するならすなわちというコマンドで指定されたノード名を見て、ローカルの決定をするべきです。 そうでなければ、適切なエラーコードはクライアントに返されるべきです。

   Otherwise, the server host should force its retry queues to start
   sending messages to that remote site, using another SMTP connection.
   At the moment, there is no requirement that a connection must occur,
   or that the connection must occur within a given time frame.  This
   should be noted in the case where there are no messages for the
   client host at the server host and only the 250 response is used.

さもなければ、サーバー・ホストは再試行待ち行列を強制的にそのリモートサイトにメッセージを送り始めさせるべきです、別のSMTP接続を使用して。 現在、接続が起こらなければならないか、または接続が与えられた時間枠の中に起こらなければならないという要件が全くありません。 クライアントホストへのメッセージが全くサーバー・ホストにない場合でこれに注意するべきです、そして、250応答だけが使用されています。

   Since the processing of the queues may take an indeterminate amount
   of time, this command should return immediately with a response to
   the client host.  The valid return codes for this command are:

待ち行列の処理が不確定の時かかるかもしれないので、このコマンドはすぐに、クライアントホストへの応答とともに帰るべきです。 このコマンドのための有効な復帰コードは以下の通りです。

   250 OK, queuing for node <x> started
   251 OK, no messages waiting for node <x>
   252 OK, pending messages for node <x> started
   253 OK, <n> pending messages for node <x> started
   458 Unable to queue messages for node <x>
   459 Node <x> not allowed: <reason>
   500 Syntax Error
   501 Syntax Error in Parameters

250 OK、ノード<x>のために列を作るのは251OKを始めて、252がノード<x>へのメッセージまで承認するノード<x>を待つどんなメッセージも253OKを始めないで、ノード<x>へのメッセージまで<n>は459Node<x>が許容しなかったノード<x>へのメッセージを列に並ばせるために458Unableを始動しました: パラメタの<理由>500構文エラー501構文エラー

   The 250 response code does not indicate that messages will be sent to
   the system in question, just that the queue has been started and some
   action will occur.  If the server is capable of supporting it, the
   251, 252 or 253 response codes should be used to give more
   information to the client side.  In this case, if there are messages
   waiting for the client side node, a check can be performed using
   these responses codes as an indication of when there are no more
   pending messages in the queue for that node.

250応答コードは問題のシステムにメッセージを送って、まさしくそれが待ち行列であることが始められて、何らかの動作が起こるのを示しません。 サーバがそれ、251、252または253をサポートすることができるなら、応答コードは、クライアント側に詳しい情報を与えるのに使用されるべきです。 この場合、クライアントサイドノードを待つメッセージがあれば、そのノードに待ち行列にそれ以上の未定のメッセージがない時のしるしとしてこれらの応答コードを使用することでチェックを実行できます。

   The 458 and 459 result codes should be used to give more information
   back to the client host as to why the action was not performed.  If
   the syntax of the request is not correct, then the 500 and 501 result
   codes should be used.

458と459の結果コードが、動作が実行されなかった理由に関してクライアントホストに詳しい情報を返すのに使用されるべきです。 要求の構文が正しくないなら、500と501の結果コードが使用されるべきです。

5.2  Client action on receiving response to extended ETRN command

5.2 拡張ETRNコマンドへの応答を受けることへのクライアント動作

   If one of the 500 level error codes (550 or 551) are sent, the client
   should assume that the protocol is not supported in the remote host
   or that the protocol has not been implemented correctly on either the
   client or server host.  In this case, multiple ETRN commands (dealing
   with the aliases for the system) should not be sent.

500レベルの1つであるなら、エラーコード(550か551)を送って、クライアントは、プロトコルがリモートホストでサポートされないか、またはプロトコルがクライアントかサーバー・ホストの上で正しく実装されていないと仮定するべきです。 この場合、複数のETRNコマンド(システムのための別名に対処する)を送るべきではありません。

De Winter                   Standards Track                     [Page 4]

RFC 1985             SMTP Service Extension - ETRN           August 1996

De冬の標準化過程[4ページ]RFC1985SMTPサービス拡張子--ETRN1996年8月

   If the 250 response is received, then the client host can assume that
   the server host found its request to be satisfactory and it will send
   any queued messages.  This process may involve going through a very
   large retry queue, and may take some time.

250応答が受け取られているなら、クライアントホストは、サーバー・ホストが、満足できるという要求とそれがどんな列に並ばせられたメッセージも送るのがわかったと仮定できます。 このプロセスは、非常に大きい再試行待ち行列に直面していることを伴って、ある程度時間がかかるかもしれません。

   If the 400 level response is received, then the client can assume
   that the server supports the command, but for some local reason does
   not want to accept the ETRN command as is.  In most cases, it will
   mean that there is a list of nodes that it will accept the command
   from and the current client is not on that list.  The 459 response
   code is presented to allow for a more in-depth reason as to why the
   remote queuing cannot be started.

400の平らな応答が受け取られているなら、クライアントは、サーバがコマンドをサポートすると仮定できますが、何らかのローカルの理由でETRNコマンドがそのままであると受け入れたがっていません。 多くの場合、それがコマンドを受け入れるノードのリストがあることを意味するでしょう、そして、現在のクライアントはそのリストにいません。 459応答コードは、リモート列を作りを始めることができない理由に関して、より徹底的な理由を考慮するために提示されます。

5.3  Use Of ETRN to release mail for a subdomain or queue

5.3は、サブドメインのためのメールを発表するか、または列を作るのにOf ETRNを使用します。

   If the requesting server wishes to release all of the mail for a
   given subdomain, a variation on the ETRN command can be used.  To
   perform this request, the option character '@' should be used in
   front of the node name.  In this manner, any domain names that are
   formed with a suffix of the specified node name are released.

要求サーバが与えられたサブドメインのためのメールのすべてをリリースしたいなら、ETRNコマンドの変化を使用できます。 この要求を実行するために、オプションキャラクタ'@'はノード名の正面で使用されるべきです。 この様に、指定されたノード名の接尾語で形成されるどんなドメイン名もリリースされます。

   For example, if the command ETRN @foo.com was issued, then any
   accumulated mail for fred.foo.com, a.b.c.d.e.f.g.foo.com or foo.com
   may be released.  It should be noted that the receiving side of the
   ETRN command should make a decision based on the client in question
   and only allow certain combinations for each of the nodes.  This is
   more of a security issue than anything else.

例えば、コマンドETRN@foo.comが発行されたなら、a.b.c.d.e.f.g.のfred.foo.com、foo.comまたはfoo.comのためのどんな蓄積されたメールも発表されるかもしれません。 ETRNコマンドの受信側が問題のクライアントに基づいて決定して、それぞれのノードのためにある組み合わせを許すだけであるはずであることに注意されるべきです。 これは他の何も安全保障問題の以上です。

   In a similar vein, it might be necessary under some circumstances to
   release a certain queue, where that queue does not correspond to a
   given domain name.  To this end, the option character '#' can be used
   to force the processing of a given queue.  In this case, the node
   name would be used as a queue name instead, and its syntactical
   structure would be dependant on the receiving server.  An example of
   this would be using the command ETRN #uucp to force the flush of a
   UUCP queue.  Note that the use of this option is entirely a local
   matter and there is no way for a client to find a list of any such
   queues that exist.

似たような仕方で、ある待ち行列をリリースするのがいくつかの状況で必要であるかもしれません、その待ち行列が与えられたドメイン名と食い違っているところで。 このために、与えられた待ち行列の処理を強制するのにオプションキャラクタ'#'を使用できます。 この場合、ノード名は代わりに待ち行列名として使用されるでしょう、そして、統語構造は受信サーバの扶養家族でしょう。この例はUUCP待ち行列の水洗を強制するコマンドETRN#uucpを使用しているでしょう。 このオプションの使用が完全に地域にかかわる事柄であり、クライアントが存在するどんなそのような待ち行列のリストも見つける方法が全くないことに注意してください。

6.  Minimal usage

6. 最小量の用法

   A "minimal" client may use this extension with its host name to start
   the queues on the server host.  This minimal usage will not handle
   cases where mail for 'x.y' is sent to 's.x.y'.

「最小量」のクライアントは、待ち行列をサーバー・ホストに始めるのにホスト名によるこの拡張子を使用するかもしれません。 'この最小量の用法は'x.y'のためのメールが発信しているのが、.x.yであるということであるケースを扱わないでしょう'。

   A minimal server may use this extensions to start the processing of
   the queues for all remote sites.  In this case, the 458 error
   response will not be seen, and it should always return the 250

最小量のサーバは、すべてのリモートサイトのための待ち行列の処理を始めるのにこの拡張子を使用するかもしれません。 この場合、458誤り応答は見られないでしょう、そして、それはいつも250を返すべきです。

De Winter                   Standards Track                     [Page 5]

RFC 1985             SMTP Service Extension - ETRN           August 1996

De冬の標準化過程[5ページ]RFC1985SMTPサービス拡張子--ETRN1996年8月

   response as it will always try and start the processing for any
   request.

どんな要求のためにもいつも試みて、処理を始めるような応答。

7. Example

7. 例

   The following example illustrates the use of remote queue processing
   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: 250-EXPN
   S: 250-HELP
   S: 250 ETRN
   C: ETRN
   S: 500 Syntax Error
   C: ETRN localname
   S: 501 Syntax Error in Parameters
   C: ETRN uu.net
   S: 458 Unable to queue messages for node uu.net
   ...

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 S: 250-EXPN S: 250助けS: 250 ETRN C: ETRN S: 500 構文エラーC: ETRN localname S: パラメタCの501構文エラー: ETRN uu.net S: 458 ノードuu.netへのメッセージを列に並ばせることができません…

   C: ETRN sigurd.innosoft.com
   S: 250 OK, queuing for node sigurd.innosoft.com started
   C: ETRN innosoft.com
   S: 250 OK, queuing for node innosoft.com started

C: ETRN sigurd.innosoft.com S: 250 OK、ノードsigurd.innosoft.comのために列を作るのはCを始めました: ETRN innosoft.com S: 250 OK、ノードinnosoft.comのために列を作るのは始まりました。

   OR

OR

   C: ETRN sigurd.innosoft.com
   S: 251 OK, no messages waiting for node sigurd.innosoft.com
   C: ETRN innosoft.com
   S: 252 OK, pending messages for node innosoft.com started
   C: ETRN mysoft.com
   S: 253 OK, 14 pending messages for node mysoft.com started

C: ETRN sigurd.innosoft.com S: 251 OK、ノードsigurd.innosoft.com Cを待たないどんなメッセージも: ETRN innosoft.com S: 252 ノードinnosoft.comへのOKの、そして、未定のメッセージはCを始めました: ETRN mysoft.com S: 253 OK、ノードmysoft.comへの14の未定のメッセージが始まりました。

   ...
   C: ETRN foo.bar
   S: 459 Node foo.bar not allowed: Unable to resolve name.
   ...
   C: QUIT
   S: 250 Goodbye

... C: ETRN foo.bar S: foo.barが許容しなかった459ノード: 名前を決議できません。 ... C: Sをやめてください: 250さよなら

De Winter                   Standards Track                     [Page 6]

RFC 1985             SMTP Service Extension - ETRN           August 1996

De冬の標準化過程[6ページ]RFC1985SMTPサービス拡張子--ETRN1996年8月

8. Security Considerations

8. セキュリティ問題

   This command does not compromise any security considerations of any
   existing SMTP or ESMTP protocols as it merely shortens the time that
   a client needs to wait before their messages are retried.

それらのメッセージが再試行される前のクライアントが、待つ必要がある時に単に短くするとき、このコマンドは、どんな存在のどんなセキュリティ問題にもSMTPに感染もしませんし、ESMTPにプロトコルに感染もしません。

   Precautions should be taken to make sure that any client server can
   only use the @ and # option characters for systems that make sense.
   Failure to implement some kind of sanity checking on the parameters
   could lead to congestion.  This would be evident if a person asking
   to release @com, which would release mail for any address that ended
   with com.

どんなクライアントサーバも理解できるシステムに@と#オプションキャラクタを使用できるだけであるのを確実にするために注意するべきです。 パラメタについて検査するある種の正気を実装しない場合、混雑につながるかもしれません。 これはcomで終わったどんなアドレスのためのメールも発表するだろう@comをリリースするように頼む人であるなら明白でしょう。

9.  Acknowledgements

9. 承認

   This document was created with lots of support from the users of our
   products, who have given some input to the functionality that they
   would like to see in the software that they bought.

このドキュメントは多くの何らかの入力を与えた私たちの製品のユーザからそれらが買ったソフトウェアのそれらが見たがっている機能性までのサポートで作成されました。

10.  References

10. 参照

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

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

   [2] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
       E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
       Nations University, Innosoft International, Inc., Dover Beach
       Consulting, Inc., Network Management Associates, Inc., The Branch
       Office, February 1993.

[2] Klensin、J.、WG議長、解放されています、N.とエディタとローズとM.とStefferud、E.とD.クロッカー、「SMTPサービス拡張子」RFC1425、国連大学、Innosoftの国際Inc.、ドーヴァービーチコンサルティングInc.、ネットワークマネージメントはInc.を関連づけます、支店、1993年2月。

11.  Author's Address

11. 作者のアドレス

   Jack De Winter
   Wildbear Consulting, Inc.
   17 Brock Street
   Kitchener, Ontario, Canada
   N2M 1X2

ジャックDe冬のWildbearコンサルティング, Inc.17Brock通りキッチナー、オンタリオ(カナダ)N2M1X2

   Phone: +1 519 576 3873
   EMail: jack@wildbear.on.ca

以下に電話をしてください。 +1 3873年の519 576メール: jack@wildbear.on.ca

De Winter                   Standards Track                     [Page 7]

De冬の標準化過程[7ページ]