RFC2852 日本語訳

Network Working Group                                           D. Newman
Request for Comments: 2852                               Sun Microsystems
Updates: 1894                                                   June 2000
Category: Standards Track

コメントを求めるワーキンググループD.ニューマン要求をネットワークでつないでください: 2852のサン・マイクロシステムズアップデート: 1894 2000年6月のカテゴリ: 標準化過程

                   Deliver By SMTP Service Extension

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 a mechanism whereby a SMTP client can request, when
   transmitting a message to a SMTP server, that the server deliver the
   message within a prescribed period of time.  A client making such a
   request also specifies the message handling which is to occur if the
   message cannot be delivered within the specified time period: either
   the message is to be returned as undeliverable with no further
   processing, or a "delayed" delivery status notification (DSN) [6] is
   to be issued.

このメモはSMTPサーバーに送信するときSMTPクライアントが、サーバが処方された期間以内にメッセージを送るよう要求できるメカニズムを定義します。 また、そのような要求をしているクライアントは指定された期間中にメッセージを送ることができないなら起こることになっているメッセージハンドリングを指定します: メッセージはさらなる処理のない「非-提出物」、または「遅らせられた」配送状態通知(DSN)[6]を発行することになっているとき返すことです。

   This extension should not be viewed as a vehicle for requesting
   "priority" processing.  A receiving SMTP server may assign whatever
   processing priority it wishes to a message transmitted with a Deliver
   By request.  A Deliver By request serves to express a message's
   urgency and to provide an additional degree of determinancy in its
   processing.  An indication of an urgent message's status within a
   given time period may be requested and will be honored.  Moreover,
   the message may be withdrawn if not delivered within that time
   period.

「優先権」処理を要求するための乗り物としてこの拡大を見なすべきではありません。 受信SMTPサーバーはそれがDeliver By要求で送られたメッセージに願っているどんな処理優先権も割り当てるかもしれません。 Deliver By要求はメッセージの緊急を言い表して、処理における、determinancyの追加度を提供するのに役立ちます。 急報の状態のしるしは、一定の時間内に要求されるかもしれなくて、光栄に思うようになるでしょう。 そのうえ、その期間中にメッセージを引き下がるか、または送るかもしれません。

   A typical usage of this mechanism is to prevent delivery of a message
   beyond some future time of significance to the sender or recipient
   but not known by the MTAs handling the message.  For instance, the
   sender may know that the message will be delivered as a page but does
   not consider the message to be sufficiently important as to warrant
   paging the recipient after business hours. In that case, the message
   could be marked such that delivery attempts are not made beyond

このメカニズムの典型的な使用法はMTAsによって送付者か受取人への意味の何らかの将来の時間通信しましたが、知られなかったaの配送がメッセージを扱うのを防ぐことです。 例えば、送付者は、営業時間後に受取人を呼び出すのを保証するくらいには、メッセージが、1ページとして渡しますが、メッセージが十分重要であると考えないのを知るかもしれません。 その場合、メッセージは配送試みがされない著しいそのようなものであるかもしれません。

Newman                      Standards Track                     [Page 1]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[1ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

   17:00.  Another common usage arises when a sender wishes to be
   alerted to delivery delays.  In this case, the sender can mark a
   message such that if it is not delivered within, say, 30 minutes, a
   "delayed" DSN is generated but delivery attempts are nonetheless
   continued.  In this case the sender has been allowed to express a
   preference for when they would like to learn of delivery problems.

17:00. 送付者を配送遅れに警告されたいとき、別の一般的な用法は起こります。 この場合、送付者は、それが中、たとえば届けられないなら、30分間「遅らせられた」DSNが発生しますが、配送試みがそれにもかかわらず、続けられているように、メッセージをマークできます。 この場合、送付者は彼らが配送問題を知りたがっている時の間、優先を言い表すことができました。

1.  Definitions

1. 定義

   Throughout this document, the term "deliver" is taken to mean the act
   of transmitting a message to its "final" destination by a message
   transport agent (MTA).  Usually, but not always, this means storing
   or otherwise handing off the message to the recipient's mailbox.
   Thus, an MTA which accepts a message to be delivered within a
   specified time period is agreeing to store or handoff the message to
   the recipient's mailbox within the specified time period.  Outside
   the scope of the term "deliver" are any user-specified actions which
   might take place after the MTA stores or hands off the message; e.g.,
   user-programmed filters which, often unbeknownst to the MTA, resend
   the message to some other location.

このドキュメント中では、「配送」という用語は、メッセージ転送エージェント(MTA)で「最終的な」目的地に送信する行為を意味するにはかかります。 いつもでない、しかし、通常、これは、メッセージを受信者のメールボックスに格納するか、またはそうでなければ、渡すことを意味します。 したがって、店か移管に同意して、指定された期間以内に渡されるべきメッセージを受け入れるMTAは指定された期間中に受信者のメールボックスへのメッセージです。 「配送」という用語の範囲の外に、MTAがメッセージを格納するか、または渡した後に行われるどんなユーザによって指定された動作もあります。 例えば、ユーザはMTAに知られずにしばしばある他の位置にメッセージを再送するフィルタをプログラムしました。

   The key words "MUST", "MUST NOT", "SHOULD" and "SHOULD NOT" in this
   document are to be interpreted as described in RFC 2119 [7].

そして、キーワード“MUST"、「必須NOT」“SHOULD"、「」 これが記録するコネはRFC2119[7]で説明されるように解釈されないべきであることですか?

2.  Framework for the Deliver By SMTP service extension

2. Deliver By SMTPサービス拡張子のための枠組み

   The Deliver By SMTP service extension uses the SMTP service extension
   mechanism described in [4].  The following SMTP service extension is
   therefore defined:

Deliver By SMTPサービス拡張子は[4]で説明されたSMTPサービス拡大メカニズムを使用します。 したがって、以下のSMTPサービス拡張子は定義されます:

   (1)  The name of the SMTP service extension is "Deliver By".

(1) SMTPサービス拡張子の名前は「配送してください」です。

   (2)  The EHLO keyword value associated with this service extension is
        "DELIVERBY".

(2) このサービス拡大に関連しているEHLOキーワード価値は"DELIVERBY"です。

   (3)  One optional parameter is allowed with this EHLO keyword value.
        The optional parameter, when supplied, is a comma separated list
        of options.  Only one option, a min-by-time, is specified in
        this document.  Future documents may extend this specification
        by specifying additional options.  The min-by-time is a fixed
        integer indicating the fixed minimum by-time that the server
        will accept when a by-mode of "R" is specified as per Section 4.

(3) 1つの任意のパラメタがこのEHLOキーワード価値で許容されています。 供給すると、任意のパラメタはオプションのコンマの切り離されたリストです。 1つのオプション(時間までに分)だけが本書では指定されます。 将来のドキュメントは、追加オプションを指定することによって、この仕様を広げるかもしれません。 時間までに分は固定最小限が、aであるときに意志がモードで受け入れる「R」のサーバがセクション4に従って指定されるように調節するのを示す固定整数です。

        The syntax of the optional parameter is as follows, using the
        augmented BNF notation of RFC 2234 [2]:

RFC2234[2]の増大しているBNF記法を使用して、任意のパラメタの構文は以下の通りです:

Newman                      Standards Track                     [Page 2]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[2ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

      deliverby-param = min-by-time *( ',' extension-token )
      min-by-time     = [1*9DIGIT]
      extension-token = 1*<any CHAR excluding SP, COMMA and all control
                           characters (US ASCII 0-31 inclusive)>
      SP               = <the space character (ASCII decimal code 32)>
      COMMA            = <the comma character (ASCII decimal code 44)>

deliverby-paramが時間までに分*と等しい、(''拡大象徴) 時間分の=[1*9DIGIT]拡大象徴が1*<と等しい、SPを除くどんなCHAR、COMMA、およびすべての制御文字(米国ASCII0-31包括的な)>SPもコンマキャラクタの間隔文字(ASCIIの10進コード32)>COMMA=<の<と等しいです。(ASCIIの10進コード44)>。

        If the parameter is omitted, no information is conveyed about
        the server's fixed minimum by-time.

パラメタが省略されるなら、情報は全く時間までにサーバの固定最小限に関して伝えられません。

   (4)  One optional parameter using the keyword "BY" is added to the
        MAIL FROM command.

(4) キーワード“BY"を使用する1つの任意のパラメタがコマンドからメールに追加されます。

   (5)  The maximum length of a MAIL FROM command line is increased by
        17 characters by the possible addition of the BY keyword and
        value.

(5) 17のキャラクタがBYキーワードと価値の可能な添加でMAIL FROMコマンドラインの最大の長さを増加させます。

   (6)  No additional SMTP verbs are defined by this extension.

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

3.  The Deliver By SMTP service extension

3. Deliver By SMTPサービス拡張子

   A SMTP client wishing to use the Deliver By SMTP service extension
   may issue the EHLO command to start a SMTP session and to determine
   if the SMTP server supports the service extension.  If the server
   responds with code 250 to the EHLO command, and the response includes
   the EHLO keyword DELIVERBY, then the Deliver By SMTP service
   extension is supported by the server.

Deliver By SMTPサービス拡張子を使用したがっているSMTPクライアントはSMTPセッションを始めて、SMTPサーバーがサービス拡大を支持するかどうか決定するEHLOコマンドを発行するかもしれません。 サーバがコード250でEHLOコマンドに反応して、応答がEHLOキーワードDELIVERBYを含んでいるなら、Deliver By SMTPサービス拡張子はサーバによってサポートされます。

   If a numeric parameter follows the DELIVERBY keyword value of the
   EHLO response then that parameter indicates the minimum value allowed
   for the by-time when a by-mode of "R" is specified with the extended
   MAIL FROM command as described in Section 4.  Any attempt by a client
   to specify a by-mode of "R" and a by-time strictly less than this
   limit, min-by-time, will be rejected with a permanent failure (55z)
   reply code.

数値パラメタが従うなら、パラメタが、aであるときに、最小値が、モードで調節していると考慮したのを示すその時の「R」のEHLO応答のDELIVERBYキーワード価値はセクション4で説明されるようにコマンドから拡張メールで指定されます。 この限界より「R」とaについてモードで厳密に調節していた状態でaを指定しないクライアントによるどんな時間分である試みも永久的な失敗(55z)回答コードで拒絶されるでしょう。

   A SMTP server that supports the Deliver By SMTP service extension
   will accept the extended version of the MAIL FROM command described
   in Section 4.  When supported by the server, a SMTP client may use
   the extended MAIL FROM command (instead of the MAIL FROM command
   described in [1]) to request that the message be delivered within the
   specified time period.  The server may then return an appropriate
   error code if it determines that the request cannot be honored.  Note
   that this may not be apparent to the server until either presentation
   of the recipient addresses with RCPT TO commands or completion of the
   transfer of the message data with the dot (.) command.  As such, the

Deliver By SMTPサービス拡張子をサポートするSMTPサーバーはセクション4で説明されたMAIL FROMコマンドの拡張版を受け入れるでしょう。 サーバによって支持されたいつ、SMTPクライアントは拡張MAIL FROMコマンドを使用するかもしれないか。(メッセージが指定された期間中に送られるよう要求するために[1])で説明されたMAIL FROMコマンドの代わりに。 そして、要求を光栄に思うことができないことを決定するなら、サーバは適切なエラーコードを返すかもしれません。 受取人のプレゼンテーションがRCPT TOと共にドットがあるメッセージデータの転送のコマンドか完成を記述するまでこれがサーバに明らかでないかもしれないことに注意してください、()、命令してください。 そのようなものとして

Newman                      Standards Track                     [Page 3]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[3ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

   server may send to the client a success response to the MAIL FROM
   command only to later return an error response to the RCPT TO, DATA,
   or dot command.

サーバは後で単にRCPT TO、DATA、またはドットコマンドへの誤り応答を返すMAIL FROMコマンドへの成功応答をクライアントに送るかもしれません。

4.  The extended MAIL FROM command

4. 拡張MAIL FROMコマンド

   The extended MAIL FROM command is issued by a SMTP client when it
   wishes to inform a SMTP server that a message is to be delivered
   within a specified period of time and further what action to take
   should the message prove undeliverable within that time period.  The
   extended MAIL FROM command is identical to the MAIL FROM command as
   defined in RFC 821 [1], except that a BY parameter appears after the
   address.

メッセージがその期間中に「非-提出物」であると判明するならどんな行動を取るかをメッセージが指定された期間以内にさらに送られることになっているSMTPサーバーに知らせたがっているとき、拡張MAIL FROMコマンドはSMTPクライアントによって発行されます。 拡張MAIL FROMコマンドはRFC821[1]で定義されるようにMAIL FROMコマンドと同じです、BYパラメタがアドレスの後に現れるのを除いて。

   The complete syntax of this extended command is defined in [4].  The
   esmtp-keyword is "BY" and the syntax for the esmtp-value is given by
   the syntax for by-value shown below.  In the augmented BNF of RFC
   2234 [2], the syntax for the BY esmtp-parameter is

この拡張コマンドの完全な構文は[4]で定義されます。 esmtp-キーワードは“BY"です、そして、構文でesmtp-値のための構文を値による示された下に与えます。 RFC2234[2]の増大しているBNFでは、BY esmtp-パラメタのための構文はそうです。

   by-parameter = "BY="by-value
   by-value     = by-time";"by-mode[by-trace]
   by-time      = ["-" / "+"]1*9digit ; a negative or zero value is not
                                      ; allowed with a by-mode of "R"
   by-mode      = "N" / "R"           ; "Notify" or "Return"
   by-trace     = "T"                 ; "Trace"

= 「=」は値で調節していた状態で=を評価します。「パラメタ、」 ; 「モード[跡のそばの]で、=[「-」/「+」]1*9digitを調節してください」。 ネガにもかかわらず、どんな値もそうではありません。 aで、モードで、モードによる「R」=「N」/「R」について許容されています。 「通知してください」か跡のそばの「リターン」=「T」。 「跡」

   Note that the BY esmtp-keyword MUST have an associated esmtp-value.
   The by-time is a decimal representation of the number of seconds
   within which the message should be delivered and has the range

BY esmtp-キーワードには関連esmtp-値がなければならないことに注意してください。 調節しているのは、メッセージが送られるべきであり、範囲を持っている秒数の10進表現です。

     -999,999,999 seconds <= by-time <= +999,999,999 seconds

+999,999,999時間までに<=<=秒の-999,999,999秒

   and is thus sufficient to represent a time anywhere from
   approximately 31.6 years in the past to 31.6 years in the future.

その結果、将来どこでも過去のおよそ31.6年から31.6年まで時間を表すために、十分です。

   As described in Section 4.1, the by-mode indicates the action the
   SMTP server must take should it not be possible to transmit the
   message within by-time seconds.

セクション4.1で説明されるようにモード、それが時間までに秒以内にメッセージを送るのにおいて可能でないならSMTPサーバーが取らなければならない行動を示します。

   Note that by-time is a delta time: the number of seconds within which
   to deliver the message.  This delta time does not extend an MTA's
   normal retention period for undeliverable messages nor is it a
   "deliver after" time.

時間までにデルタ時間である注意: メッセージを送る秒数。 このデルタ時間は「非-提出物」メッセージのためにMTAの正常な保有の期間を延ばしていません、そして、「後に配送してください」時間ではありません。

   A delta time is used so as to prevent problems associated with
   differences in system clocks between clients and servers.  Servers in
   receipt of a valid by-parameter are expected to convert the by-time
   into a locale-specific absolute time called the deliver-by-time.

デルタ時間は、クライアントとサーバの間のシステムクロックの違いに関連している問題を防ぐのに使用されています。 aを受け取って有効なサーバが、調節しているのを時間で配送していると呼ばれる現場特有の絶対時間に変換するとパラメタによって予想されます。

Newman                      Standards Track                     [Page 4]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[4ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

   This is done by adding the by-time upon receipt to the current
   locale-specific time and thereby arriving at a locale-specific
   absolute time which is by-time seconds in the future or past,
   depending upon the arithmetic sign of by-time.  The message is then
   to be delivered by the deliver-by-time.  The sending client and
   receiving server should assume the transmission time of the MAIL FROM
   command to be instantaneous.  Clearly, it will not be and network
   latency will introduce an error, the nature of which will be to
   extend slightly the effective by-time. The more hops the message
   takes, the more pronounced the effect will be owing to the cumulative
   nature of this latency-induced error.

領収書で調節していると現在の現場特有の時間に言い足すことによって、これをします、そして、その結果、時間までに秒である現場特有の絶対時間に演算によるのが将来か過ぎて、サインする到着するのは調節されます。 そして、メッセージによって配送されることになっています。時間で、配送しています。 送付クライアントと受信サーバは、MAIL FROMコマンドのトランスミッション時間が瞬時に起こっていると仮定するべきです。 明確に、そうにならないでしょう、そして、ネットワーク潜在は時間までに有効をわずかに広げるそれの自然がことである誤りを導入するでしょう。 メッセージが取るホップが多ければ多いほど、より多くが、効果がこの潜在で誘発された誤りの累積している本質のためにあると断言しました。

   In the case of a by-mode of "N", it is possible that by-time may be
   zero or negative.  This is not an error and should not be rejected as
   such.  It indicates a message for which the deliver-by-time occurred
   -(by-time) seconds in the past.  [Here, "-(by-time)" represents the
   arithmetic negation of the by-time value.]  Zero and negative values
   are allowed so as to preserve information about any requested
   delivery time information -- information which the delivering MTA may
   wish to include with the delivered message for the benefit of the
   recipient or to show in a DSN or NDN (non delivery notification).

aに関するケース、モード、「N」では、時間までに、それがゼロかネガであることが可能です。 これを誤りでなく、そういうものとして拒絶するべきではありません。 それは時間で配送しているのが起こったメッセージを示します--過去の(時間までに)秒。 [ここ、「-、(時間までに)、」、算数の否定を表す、時間的価値、]。 ゼロと負の数はどんな要求された納期情報の情報も保存するために許容されています--配送しているMTAが受取人の利益かDSNかNDN(非配送通知)で目立つ渡されたメッセージで含みたがっているかもしれない情報。

   In the case of a by-mode of "R", a zero or negative by-time is a
   syntax error. In such a case, the SMTP server SHOULD return a
   permanent failure (501) SMTP reply code in response to the extended
   MAIL FROM command.  If the SMTP server also supports enhanced error
   codes [8], then an enhanced error code of 5.5.4 SHOULD also be
   returned.

aに関するケース、モード、「R」では、ゼロかネガが調節するaは構文エラーです。 このような場合には、SMTPサーバーSHOULDは拡張MAIL FROMコマンドに対応して永久的な失敗(501)SMTP回答コードを返します。 また、SMTPサーバーであるなら、サポートはエラーコード[8]を高めて、次に、5.5の高められたエラーコードは.4SHOULDです。また、返します。

   If the by-time is a valid by-time specification but the SMTP server
   cannot honor or accept it for a server-specific reason, then SMTP
   server SHOULD respond with either a 455 SMTP response if the
   condition is transient or a 555 SMTP response if the condition is
   permanent. In addition, if the SMTP server also supports [8], a
   suitable 4.X.X or 5.X.X enhanced error code SHOULD also be returned.

時間までに調節しているのが、有効な仕様ですが、SMTPサーバーがサーバ特有の理由でそれを光栄に思うことができませんし、受け入れることができないなら、状態が永久的であるなら、SMTPサーバーSHOULDは455SMTP応答で状態が一時的であるか、そして、555SMTP応答を反応させます。 添加の適当な4.X.Xかまた、SMTPサーバーが[8]を支持するなら5.X.X高められたエラーコードSHOULDではも、返してください。

4.1.  Server behavior upon receipt of the extended MAIL FROM command

4.1. 拡張MAIL FROMコマンドを受け取り次第サーバの振舞い

   Upon receipt of an extended MAIL FROM command containing a valid BY
   parameter, a SMTP server and associated MTA must handle the message
   in accord with the following subsections, Sections 4.1.1-4.1.5.
   Delivery status notifications generated in response to processing a
   message with a Deliver By request should include both the optional
   Arrival-Date DSN field as well as the new Deliver-By-Date DSN field
   described in Section 5 of this memo.

有効なBYパラメタを含む拡張MAIL FROMコマンドを受け取り次第、SMTPサーバーと関連MTAは以下の小区分、セクション4.1.1-4.1.5に合っているメッセージを扱わなければなりません。 Deliver By要求でメッセージを処理することに対応して発生する配送状態通知は任意のArrival-日付のDSN分野とこのメモのセクション5で説明された新しい日付によるDeliver DSN分野の両方を含むべきです。

Newman                      Standards Track                     [Page 5]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[5ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

   A by-time Note that a message's by-time does not extend the MTA's
   normal message retention period: an MTA MAY return a message as
   undeliverable before the deliver-by-time has been reached.

時間までにメッセージのものが調節するNoteはMTAの正常なメッセージ保有の期間を延ばしていません: 時間で配送している前の「非-提出物」に達したとき、MTA MAYはメッセージを返します。

4.1.1.  Successful delivery

4.1.1. うまくいっている配送

   If the message is delivered before deliver-by-time, no special action
   need be taken.  If the SMTP server or MTA also supports the Delivery
   Status Notification SMTP service extension [5] and a NOTIFY parameter
   including "SUCCESS" was specified, a "delivered" DSN with appropriate
   status must be returned as per [5].

以前メッセージを送るなら、時間で配送してください、そして、どんな特別な行動も取る必要はありません。 また、SMTPサーバーかMTAがDelivery Status Notification SMTPサービス拡張子[5]とNOTIFYパラメタをサポートするなら、「成功」を含んでいるのを指定して、[5]に従って適切な状態がある「渡された」DSNを返さなければなりません。

4.1.2.  Unsuccessful delivery; deliver-by-time not yet reached

4.1.2. 失敗の配送。 時間で、まだ達していなく、配送してください。

   If deliver-by-time has not yet passed and the message has proved
   undeliverable for temporary reasons, then the SMTP server or MTA
   should continue delivery or relay attempts as per the site's message
   handling policy.  If the MTA's message retention period is less than
   by-time, the MTA MAY return the message as undeliverable before
   deliver-by-time has been reached.  However, the message MUST still be
   handled in accord with Sections 4.1.1-4.1.5.

時間で配送している、まだ通っていない、メッセージは一時的な理由(SMTPサーバーかMTAがサイトのメッセージハンドリング方針単位で配送かリレー試みを続けているはずであるその時)で「非-提出物」であると判明しました。 MTAのメッセージ保有の期間が時間より少ないなら、時間で配送している前に「非-提出物」に達したとき、MTA MAYはメッセージを返します。 しかしながら、まだセクション4.1.1-4.1.5に合った状態でメッセージを扱わなければなりません。

   If deliver-by-time has not yet passed and the message cannot be
   delivered for permanent reasons, then the SMTP server or MTA MUST
   return a "failed" DSN with an appropriate status for each recipient
   address with either no NOTIFY parameter specified or for which the
   NOTIFY parameter includes "FAILURE".

時間で配送している、まだ通っていない、永久的な理由(NOTIFYパラメタが全く指定されていなくSMTPサーバーかMTAがそれぞれの受取人アドレスのために適切な状態がある「失敗した」DSNを返さなければならない、さもなければNOTIFYパラメタが「失敗」を含んでいるその時)でメッセージを送ることができません。

4.1.3.  Time has expired; deliver-by-time reached or passed

4.1.3. 時間は期限が切れました。 時間で、達しているか、または通過されて、配送してください。

   If the message is not delivered or relayed before deliver-by-time and
   a by-mode of "R" was specified, no further delivery attempts may be
   made for the message.  The server or MTA MUST issue a "failed" DSN
   with status 5.4.7, "delivery time expired", for each recipient
   address with either no NOTIFY parameter specified or for which the
   NOTIFY parameter includes "FAILURE".

時間で配送している前に、メッセージを送りもしませんし、リレーもしないか、そして、a、モード、「R」において試みがメッセージのためにされるかもしれない指定されて、より遠い配送はそうです。 サーバかMTAが状態がある「失敗した」DSNを発行しなければならない、5.4、.7、どんなNOTIFYパラメタも指定しなかったか、またはNOTIFYパラメタが「失敗」を含んでいるどちらかがあるそれぞれの受取人アドレスのために「納期は期限が切れました」。

   If the message is not delivered or relayed before deliver-by-time and
   a by-mode of "N" was specified, the server or MTA should continue
   attempts to deliver or relay the message using the site's message
   handling policy.  In addition, the server or MTA MUST issue a
   "delayed" DSN with status 4.4.7, "delivery time expired", for each
   recipient address with either no NOTIFY parameter specified or for
   which the NOTIFY parameter includes "DELAY".

時間で配送している前に、メッセージを送りもしませんし、リレーもしないか、そして、a、モード、「N」は指定されて、サーバかMTAがサイトのメッセージハンドリング方針を使用することでメッセージを送るか、またはリレーする試みを続けているはずです。 中では、添加、サーバまたはMTAが状態がある「遅らせられた」DSNを発行しなければならない、4.4、.7、どんなNOTIFYパラメタも指定しなかったか、またはNOTIFYパラメタが「遅れ」を含んでいるどちらかがあるそれぞれの受取人アドレスのために「納期は期限が切れました」。

Newman                      Standards Track                     [Page 6]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[6ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

4.1.4.  Relaying to another SMTP server

4.1.4. 別のSMTPサーバーへのリレー

   Sections 4.1.4.1 and 4.1.4.2 below describe when a message with a
   Deliver By request may be relayed to another SMTP server and what
   additional actions, if any, should or must be taken.  In addition to
   that discussed in those sections, the following must also be observed
   when relaying is permitted.

そして、セクション4.1 .4 .1、4.1 .4 .2未満は、もしあればどんな追加行動を取らなければならないべきであるか、Deliver By要求があるメッセージがいつ別のSMTPサーバーにリレーされるかもしれないか、そして、または取らなければならないかを説明します。 また、それらのセクションで議論したそれに加えて、リレーが受入れられる以下を観測しなければなりません。

   If the message is relayed to a SMTP server that supports the Deliver
   By extension, a new BY parameter MUST be relayed specifying a by-time
   value indicating the number of seconds remaining until deliver-by-
   time.  The new by-time value should be computed as close to the time
   the MAIL FROM command is transmitted by the relaying SMTP client as
   is reasonably possible. Note that if deliver-by-time has passed, the
   relayed by-time will be a negative value indicating how may seconds
   has elapsed since delivery-by-time.  Such a case -- relay of a
   message for which deliver-by-time has just arrived or passed -- may
   only happen with a message that has a by-mode of "N".

メッセージがDeliver By拡張子をサポートするSMTPサーバーにリレーされるなら、近く配送する時間まで残っている秒数を示しながら時間的価値でaを指定して、新しいBYパラメタをリレーしなければなりません。 新しさはMAIL FROMコマンドが合理的に可能であるようにリレーしているSMTPクライアントによって伝えられる時の近くように時間的価値によって計算されるべきです。 時間で配送しているなら終わったメモ、リレーはその方法を示すのがそうする負の数が秒であったなら時間までにそうするでしょう。時間までに配送以来、経過しています。 どれが時間によって配送されるかがちょうど到着したところであるか、または通過されて、aのリレーが通信するというそのような場合はモードでaを持っている「N」に関するメッセージで起こるだけであるかもしれません。

   When a message with a by-trace field with value "T" is relayed, a
   "relayed" DSN SHOULD be generated by the relaying SMTP client for
   each recipient which either did not specify a NOTIFY parameter or the
   NOTIFY parameter does not have the value "NEVER".

パラメタに通知してください。または、値「T」がある分野が跡のそばにあるメッセージがリレーされるとき、リレーしているSMTPクライアントによって、aを指定しなかった各受取人がパラメタに通知するので、「リレーされた」DSNが発生するべきである、値の“NEVER"を持っていません。

   Note that these "relayed" DSNs are generated regardless of whether
   success notifications were explicitly requested with a NOTIFY=SUCCESS
   parameter.  Note further that the "relayed" DSNs discussed here are
   not terminal notifications:  downstream SMTP servers and MTAs may
   still support [5] and as such additional notifications may still
   result.

成功通知がNOTIFY=SUCCESSパラメタで明らかに要求されたかどうかにかかわらずこれらの「リレーされた」DSNsが発生することに注意してください。 ここで議論した「リレーされた」DSNsが端末の通知でないことにさらに注意してください: 川下では、SMTPサーバーとMTAsがまだ[5]を支持しているかもしれません、そして、そういうものとして、追加通知がまだ結果として生じているかもしれません。

4.1.4.1.  Relaying a message with a by-mode of "R"

4.1.4.1. aで、モードで、「R」は伝言を伝えます。

   A message for which a by-mode of "R" was specified MUST NOT be
   relayed to a SMTP server which does not support the Deliver By SMTP
   service extension.  Moreover, the server to which it is relayed MUST
   NOT have a fixed minimum by-time which is greater than the time
   remaining in which the message is to be delivered.  The fixed minimum
   by-time is expressed by the optional deliverby-param discussed in
   Section 2.

Aがどのaのためにモードで通信するか、「R」による指定されて、サポートではなく、そうするSMTPサーバーにリレーされてはいけないということであった、SMTPサービス拡張子で、配送してください。 そのうえ、それがリレーされるサーバは時間までに固定最小限を持ってはいけません(渡されるメッセージがことである時間の残りよりすばらしいです)。 固定最小限は時間までにセクション2で議論した任意のdeliverby-paramによって言い表されます。

   If the message requires relaying in order to be delivered yet cannot
   be relayed, then the message is deemed to be undeliverable for
   permanent reasons and Section 4.1.2 should be applied.

メッセージを渡すためにリレーするのが必要ですが、リレーできないならメッセージが永久的な理由で「非-提出物」であると考えられて、セクション4.1.2は適用されるべきです。

Newman                      Standards Track                     [Page 7]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[7ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

4.1.4.2.  Relaying a message with a by-mode of "N"

4.1.4.2. aで、モードで、「N」は伝言を伝えます。

   A message with a by-mode of "N" may be relayed to another server
   regardless of whether or not the SMTP server to which it is relayed
   supports the Deliver By extension.

にかかわらず、Aがaで「N」5月についてモードで通信する、別のサーバにリレーされてください、それがリレーされたサポートであるSMTPサーバー、拡大で、配送してください。

   If the message is relayed before deliver-by-time to a SMTP server
   that does not support the Deliver By extension, then the relaying
   SMTP client MUST issue a "relayed" DSN for each recipient which
   either did not specify a NOTIFY parameter or the NOTIFY parameter
   does not have the value "NEVER". Further, if the SMTP server being
   relayed to supports the Delivery Status Notification SMTP service
   extension [5] then for each recipient: if no NOTIFY parameter was
   supplied, "NOTIFY=FAILURE,DELAY" SHOULD be requested; if a NOTIFY
   parameter was specified and does not have the value "NEVER", "DELAY"
   SHOULD be added to the list of notify-list-element values if not
   already present.  Note that this explicitly overrides the "MUST NOT"
   wording of Section 6.2.1(c) of [5].

次に、リレーしているSMTPクライアントが各受取人のためのNOTIFYパラメタを指定しなかった「リレーされた」DSNを発行しなければならない、メッセージが以前リレーされるなら、時間でDeliver By拡張子をサポートしないSMTPサーバーに配送してください、またはさもなければ、NOTIFYパラメタには値の“NEVER"がありません。 さらに、SMTPサーバーであるなら、サポートにリレーされて、Delivery Status Notification SMTPは[5] その時、各受取人のために拡大を修理します: NOTIFYパラメタを全く提供しないなら、「=失敗、遅れに通知してください」を要求するでしょうに。 NOTIFYパラメタが指定されて、値の“NEVER"を持っていないなら、「遅れ」は、リスト要素に通知している値のリストに追加されているか、または既に存在しているべきです。 これが明らかに[5]のセクション6.2.1(c)の「必須NOT」言葉遣いをくつがえすことに注意してください。

4.1.5.  Relaying to a foreign mail system

4.1.5. 外国メールシステムへのリレー

   If the foreign mail system supports semantics similar to the Deliver
   By SMTP service extension described in this memo, then convey the
   Deliver By request to that system.  Otherwise, relay the message as
   if relaying to a SMTP server which does not support the Deliver By
   extension.

外国メールシステムがこのメモで説明されたDeliver By SMTPサービス拡張子と同様の意味論を支持するなら、Deliver By要求をそのシステムに伝えてください。 さもなければ、まるでDeliver By拡張子をサポートしないSMTPサーバーにリレーするかのようにメッセージをリレーしてください。

5.  Delivery status notifications and extension

5. 配送状態通知と拡大

   The format of delivery status notifications (DSNs) is specified in
   [6].  DSNs generated in response to a Deliver By request should
   include an Arrival-Date DSN field.  This memo also extends the per-
   message-fields of [6] to include a new DSN field, Deliver-By-Date,
   indicating the deliver-by-time as computed by the MTA or SMTP server
   generating the DSN.  In the augmented BNF of RFC 822 [2], per-
   message-fields is therefore extended as follows:

配送状態通知(DSNs)の形式は[6]で指定されます。 Deliver By要求に対応して発生するDSNsはArrival-日付のDSN分野を含んでいるはずです。 また、このメモが広がっている、-、新しいDSNを含む[6]のメッセージ分野は日付DeliverにMTAによって計算されるように時間で配送しているのを示すか、DSNを発生させるSMTPサーバーをさばきます。 RFC822[2]の増大しているBNFで-、したがって、メッセージ分野は以下の通り拡張しています:

     per-message-fields =
         [ original-envelope-id-field CRLF ]
         reporting-mta-field CRLF
         [ dsn-gateway-field CRLF ]
         [ received-from-mta-field CRLF ]
         [ arrival-date-field CRLF ]
         [ deliver-by-date-field CRLF ]
         *( extension-field CRLF )
     deliver-by-date-field = "Deliver-by-date" ":" date-time

「メッセージ分野に従って、(拡大分野CRLF)が年月日欄を果たす=[元の封筒イド分野CRLF]報告しているmta分野CRLF[dsnゲートウェイ分野CRLF][mta分野から容認されたCRLF][到着年月日欄CRLF][年月日欄のそばを果たしているCRLF]*は「日付で、配送してください」と等しい」:、」 日付-時間

Newman                      Standards Track                     [Page 8]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[8ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

   where date-time is a RFC 822 [2] date-time field as ammended by RFC
   1123 [3].

日付-時間がRFC1123[3]によってammendedされるRFC822[2]日付-時間分野であるところ。

6.  Examples

6. 例

   In the following sample SMTP dialog, the SMTP client requests that a
   message from <eljefe@bigbiz.com> be delivered to
   <topbanana@other.com> within 2 minutes (120 seconds) and returned
   otherwise.  This request takes the form of a BY parameter on the MAIL
   FROM line of "BY=120;R" as shown below:

(120秒)を書き留めます。以下のサンプルSMTP対話では、SMTPクライアントがそのaメッセージ from <eljefe@bigbiz.com を要求する、gt;、 to <topbanana@other.com を届けてください、gt;、そうでなければ、中に、2は、戻りました。 この要求がFROMが立ち並ぶメールに関するBYパラメタの形を取る、「以下に示される=120;R」で:

     S: 220 acme.net SMTP server here
     C: EHLO bigbiz.com
     S: 250-acme.net
     S: 250 DELIVERBY
     C: MAIL FROM:<eljefe@bigbiz.com> BY=120;R
     S: 250 <eljefe@bigbiz.com> sender ok
     C: RCPT TO:<topbanana@other.com>
     S: 250 <topbanana@wherever.com> recipient ok

S: ここの220acme.net SMTPサーバー、C: EHLO bigbiz.com S: 250-acme.net S: 250 DELIVERBY C: FROM:<eljefe@bigbiz.com に郵送してください、gt;、=120 ; R Sで: 250 <eljefe@bigbiz.com 、gt;、送付者OK C: RCPT TO:<topbanana@other.com 、gt;、S: 250 <topbanana@wherever.com 、gt;、受取人OK

   Suppose now that the receiving SMTP server in the above example needs
   to relay the message to another SMTP server, mail.other.com.  Owing
   to the original by-mode of "R", the message may only be relayed to
   another SMTP server which supports the Deliver By extension (Section
   4.1.4).  Further, when relaying the message, the Deliver By request
   must be relayed.  With this in mind, consider the following SMTP
   dialog:

上記の例の受信SMTPサーバーが、別のSMTPサーバー(mail.other.com)にメッセージをリレーする必要があるので、思ってください。 「R」でモードでオリジナルです、メッセージが別のSMTPサーバーにリレーされるだけであるかもしれない、どのサポート、拡大(セクション4.1.4)で、配送してくださいか。 メッセージをリレーするとき、さらに、Deliver By要求をリレーしなければなりません。 これが念頭にある状態で、以下のSMTP対話を考えてください:

     S: 220 mail.other.com ESMTP server at your service
     C: EHLO acme.net
     S: 250-mail.other.com
     S: 250 DELIVERBY 240
     C: QUIT

S: あなたのサービスCにおける220mail.other.com ESMTPサーバ: EHLO acme.net S: 250-mail.other.com S: 250 DELIVERBY240C: やめてください。

   In the above dialog, the relaying SMTP server, acme.net, connects to
   mail.other.com and issues an EHLO command.  It then learns that the
   Deliver By extension is supported but that the minimum by-time for a
   by-mode of "R" is 4 minutes (240 seconds).  This value exceeds the
   message's original by-time and therefore necessarily exceeds the
   remaining by-time.  The relaying SMTP server thus ends the SMTP
   session after which it must either attempt to follow any other MX
   records or, if there are no more MX records to follow, must return
   the message as undeliverable.  Similar behavior would result if the
   EHLO command was met with an error or did not include the DELIVERBY
   keyword.

上の対話では、リレーSMTPサーバー(acme.net)はEHLOコマンドをmail.other.comと問題に関連づけます。 次に、それは学びます。最小限が調節されていなかったならDeliver By拡張子がaのために「R」についてモードでサポートされるのは、4分(240秒)です。 この値が必ず、したがって、オリジナルが調節するメッセージのものを超えている、超過、残りは調節されます。 その結果、リレーSMTPサーバーは「非-提出物」としてそれがいかなる他のMX記録にも従うのを試みなければならないか、または従うそれ以上のMX記録が全くなければメッセージを返さなければならないSMTPセッションを終わらせます。 EHLOコマンドが誤りで満たされたか、またはDELIVERBYキーワードを含んでいないなら、同様の振舞いは結果として生じるでしょうに。

   Consider instead, the relaying SMTP session:

代わりにリレーしているSMTPセッションを考えてください:

Newman                      Standards Track                     [Page 9]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[9ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

     S: 220 mail.other.com ESMTP server at your service
     C: EHLO acme.net
     S: 250-mail.other.com
     S: 250 DELIVERBY 30
     C: MAIL FROM:<eljefe@bigbiz.com> BY=98;R
     S: 250 <eljefe@bigbiz.com> Sender okay
     C: RCPT TO:<topbanana@other.com>
     S: 250 <topbanana@wherever.com> Recipient okay

S: あなたのサービスCにおける220mail.other.com ESMTPサーバ: EHLO acme.net S: 250-mail.other.com S: 250 DELIVERBY30C: FROM:<eljefe@bigbiz.com に郵送してください、gt;、=98 ; R Sで: 250 <eljefe@bigbiz.com 、gt;、送付者承認C: RCPT TO:<topbanana@other.com 、gt;、S: 250 <topbanana@wherever.com 、gt;、受取人承認

   In the above, the relaying SMTP client relays the BY parameter with
   the by-mode preserved and the by-time computed to be the remaining
   number of seconds at the approximate time that the MAIL FROM command
   was transmitted from the relaying SMTP client (acme.net) to the
   receiving SMTP server (mail.other.com).  In this example, 22 seconds
   have elapsed since acme.net received the MAIL FROM line from the
   original sending client and relayed the Deliver By request to
   mail.other.com.

そして、上、SMTPクライアントがBYパラメタをリレーするリレー、モードで保存される、調節しているのは、MAIL FROMコマンドがリレーしているSMTPクライアント(acme.net)から受信SMTPサーバー(mail.other.com)まで伝えられた大体の秒時間の残っている数になるように計算されました。 この例では、acme.netがオリジナルの送付クライアントからMAIL FROM台詞を受けて、Deliver By要求をmail.other.comにリレーして以来、22秒は経過しています。

7.  MX based relaying considerations

7. 問題をリレーしながら基づくMX

   Sites which wish to use the Deliver By SMTP service extension and
   which direct their mail via MX records [9] need to ensure that all of
   their MX hosts -- hosts to which their mail is directed by MX records
   -- support the Deliver By extension. SMTP clients which support
   Deliver By SHOULD NOT attempt multiple MX hosts looking for one which
   supports Deliver By.

Deliver By SMTPサービス拡張子を使用することを願って、MX記録[9]でそれらのメールを指示するサイトは、彼らのMXホスト(彼らのメールがMX記録によって向けられるホスト)が皆、Deliver By拡張子をサポートするのを保証する必要があります。 Deliver Byを支持するものを探している複数のMXがDeliver By SHOULDが試みないそれのサポートを主催するSMTPクライアント。

   MX hosts should pay careful attention to the min-by-time value they
   present in response to EHLO commands.  It is not practical for an MX
   host to present a value which either (1) is substantially different
   from that which can be handled by the destination host to which it
   relays, or (2) doesn't recognize normal delivery latencies introduced
   when the MX host relays mail to the destination host.

MXホストは時間的価値による彼らがEHLOコマンドに対応して提示する分に関する慎重な注意を向けるべきです。 MXホストがあて先ホストが扱うことができるそれからそれがリレーするものまで異なった状態で(1)が実質的にそうである値を提示するように、それが実用的でないか、または(2)はMXホストがあて先ホストにメールをリレーするとき導入された正常分娩潜在を認識しません。

8.  Security Considerations

8. セキュリティ問題

   Implemention of Deliver By allows tracing of a mail transport system.
   The by-trace field "T" explicitly requests that a trace be generated.
   Moreover, even when the by-trace field is not used, a crude trace may
   be generated by entering a series of messages into the transport
   system, each with successively increasing by-time values; e.g.,
   "BY=0;R", "BY=1;R", "BY=2;R". Probing, and in some cases tracing, can
   be accomplished through other means: querying the visible SMTP
   servers, investigating Received: header lines in bounced messages,
   and using utilities such as "traceroute".

Deliver ByのImplementionはメール輸送システムをたどることを許します。 跡のそばの分野「T」は、跡が発生するよう明らかに要求します。 跡のそばの分野が使用されてさえいないとき、そのうえ、粗雑な跡は一連のメッセージを輸送システムに入力することによって、発生するかもしれません、それぞれ相次ぐ時間的価値で増加するのに。 例えば、「=0;R」で「=1;R」で「=2;R」で。 他の手段で調べ、いくつかの場合およびたどることを達成できます: Receivedを調査して、目に見えるSMTPサーバーについて質問します: ヘッダーは送り返されたメッセージと、「トレースルート」などのユーティリティを使用する際に立ち並んでいます。

Newman                      Standards Track                    [Page 10]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[10ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

9.  Other Considerations

9. 他の問題

   SMTP servers which support the Deliver By SMTP service extension as
   well as their associated MTAs are not required to assign any special
   processing priority to messages with Deliver By requests.  Of course,
   some SMTP servers and MTAs may do so if they desire.  Moreover,
   delivery status notifications generated in response to messages with
   Deliver By requests are not required to receive any special
   processing.  Consequently, users of this service should not, in
   general, expect expedited processing of their messages.  Moreover,
   just because a message is sent with a "BY=60;R" parameter does not
   guarantee that the sender will learn of a delivery failure within any
   specified time period as the DSN will not necessarily be expedited
   back to sender.

それらの関連MTAsと同様にDeliver By SMTPサービス拡張子をサポートするSMTPサーバーは、Deliver By要求でメッセージのどんな特別な処理優先権も割り当てるのに必要ではありません。 もちろん、いくつかのSMTPサーバーとMTAsが彼らであるならそうするかもしれません。願望。 そのうえ、Deliver By要求があるメッセージに対応して発生する配送状態通知は、どんな特別な処理も受けるのに必要ではありません。 その結果、一般に、このサービスのユーザは彼らのメッセージの速められた処理を予想するべきではありません。 aと共にメッセージをそのうえ、ただ送る、「=60で; R」パラメタは、DSNが必ず送付者に速めて戻されるというわけではないとき送付者がどんな指定された期間以内にも配信障害を知るのを保証しません。

10.  Acknowledgments

10. 承認

   The author wishes to thank Keith Moore for providing much of the
   initial impetus for this document as well as the basic ideas embodied
   within it.  Further thanks are due to Ned Freed and Chris Newman for
   their reviews of this document and suggestions for improvement.

作者は、それの中で具体化された基本的な考え方と同様にこのドキュメントに初期の起動力の多くを供給して頂いて、キース・ムーアに感謝したがっています。 さらなる感謝は彼らのこのドキュメントと改善提案のレビューのためのネッド・フリードとクリス・ニューマンのためです。

Newman                      Standards Track                    [Page 11]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[11ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

11.  References

11. 参照

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

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

   [2]  Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

[2]クロッカー、D.、エディタ、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

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

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

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

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

   [5]  Moore, K., "SMTP Service Extension for Delivery Status
        Notifications", RFC 1891, January 1996.

[5] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、1996年1月。

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

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

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

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

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

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

   [9]  Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
        974, January 1986.

[9] ヤマウズラ、C.が「ルート設定とドメインシステムを郵送する」、STD14、RFC974、1月1986日

12.  Author's Address

12. 作者のアドレス

   Dan Newman
   Sun Microsystems, Inc.
   1050 Lakes Drive, Suite 250
   West Covina, CA  91790
   USA

ダンニューマンサン・マイクロシステムズ・インク1050の湖ドライブ、Suite250ウエストコビナ、カリフォルニア91790米国

   Phone: +1 626 919 3600
   Fax:   +1 626 919 3614
   EMail:  dan.newman@sun.com

以下に電話をしてください。 +1 626 919、3600Fax: +1 3614年の626 919メール: dan.newman@sun.com

Newman                      Standards Track                    [Page 12]

RFC 2852           Deliver By SMTP Service Extension           June 2000

ニューマン標準化過程[12ページ]RFC2852はサービス拡大2000年6月にSMTPで配送します。

13.  Full Copyright Statement

13. 完全な著作権宣言文

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

Newman                      Standards Track                    [Page 13]

ニューマン標準化過程[13ページ]