Network Working Group D. Newman
Request for Comments: 2852 Sun Microsystems
Updates: 1894 June 2000
Category: Standards Track
Deliver By SMTP Service Extension
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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サーバは、要求により配信で送信されたメッセージを希望するどのような処理優先割り当ててもよいです。 A要求によって配信メッセージの緊急性を発現させるために、その処理に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
このメカニズムの一般的な使用方法は、メッセージを処理するのMTAによって知られている送信者または受信者ではなくに意義のある未来の時間を超えてメッセージの配信を防ぐためです。例えば、送信者はメッセージがページとして配信されますが、営業時間後に受信者をページング保証するよう十分に重要であるとのメッセージを考慮していないことを知っているかもしれません。その場合、メッセージは配信試行を超えて行われないようにマークすることができ
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が生成されますが、配達の試みが、それにもかかわらず継続されるようにメッセージをマークすることができます。この場合、送信者は、彼らは配送問題の勉強したいときのための好みを表現するために許可されています。
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」、「MUST NOT」、「SHOULD」および「SHOULD NOT」本書ではRFC 2119に記載されるように解釈されるべきである[7]。
The Deliver By SMTP service extension uses the SMTP service extension mechanism described in [4]. The following SMTP service extension is therefore defined:
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）一つのオプションのパラメータは、このEHLOキーワード値で許可されます。オプションのパラメータは、供給されたときに、オプションのカンマ区切りのリストです。オプションのみ、分ごとの時間は、この文書で指定されています。将来の文書が追加のオプションを指定することによって、この仕様を拡張することができます。分ごとの時間によるモード「R」の第4章ごとに指定された場合、サーバが受け入れることによって時間固定最小値を示す一定の整数です。
The syntax of the optional parameter is as follows, using the
augmented BNF notation of RFC 2234 [2]:
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 =分ごとに時間*（ '' 拡張トークン）分ごとに時間SP、COMMA、すべての制御文字を除く= [1 * 9DIGIT]拡張トークン= 1 * <任意のCHAR（米国ASCII 0 -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）「による」キーワードを使用して一つのオプションのパラメータは、MAIL FROMコマンドに付加されます。
(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）コマンドラインからMAILの最大長さは、BYキーワードと値の可能な添加により17文字だけ増加させます。
(6) No additional SMTP verbs are defined by this extension.
（6）追加の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.
SMTPサービス拡張により、お届け利用したいSMTPクライアントがSMTPセッションを開始すると、SMTPサーバがサービス拡張をサポートしているかどうかを判断するためにEHLOコマンドを発行することができます。サーバーがEHLOコマンドにコード250で応答し、応答がEHLOキーワードDELIVERBYが含まれている場合は、サーバーでサポートされている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.
数値パラメータは、EHLO応答のDELIVERBYキーワード値を以下の場合は、そのパラメーターは、許容される最小値を示すことによって、時間の任意のセクション4に記載されているように、「R」のモードによって命令から延長MAILで指定されていますクライアントによる試みは、「R」のバイ・モードとでタイムこの制限より厳密に小さい、MIN-バイ・時間、永続的なエラー（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 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.
サーバーでサポートされている場合はSMTPサービス拡張による配達をサポートしているSMTPサーバーは、SMTPクライアントがコマンドFROM（代わりに説明したMAIL FROMコマンドの拡張されたMAILを使用することができ、第4節で説明したMAIL FROMコマンドの拡張版を受け付けます[1]）メッセージが指定された時間期間内に配信されることを要求します。それは、要求を光栄にすることができないと判断した場合、サーバは、適切なエラーコードを返すことがあります。受信者のいずれかの提示がコマンドにRCPTまたはドット（。）コマンドを使用して、メッセージデータの転送が完了するとアドレスまで、このサーバには明らかではないかもしれないことに留意されたいです。そのため、サーバは、後でエラーRCPT TO、データに応じて、またはドットコマンドを返すために、クライアントに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サーバーに通知したいときにFROMコマンドの拡張MAILはSMTPクライアントによって発行されます。 RFC 821で定義されているコマンドから延びMAILは、MAIL FROMコマンドと同一である[1]、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値の構文です。 RFC 2234の拡張BNF [2]、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"
バイ値 "= BY" =パラメータによってバイ値=時間によって ";" によってモード[によるトレース]により、時間= [ " - " / "+"] 1 * 9digit。負またはゼロの値ではありません。バイモード=「N」/「R」「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
-999999999秒<=バイ・時間<= 999999999秒
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.
クライアントとサーバ間のシステムクロックの違いに関連する問題を防止するために、デルタ時間が使用されています。バイ・パラメータ有効なの領収書のサーバを提供することで、タイムと呼ばれるロケール固有の絶対時間にすることにより、時間に変換することが期待されています。
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).
バイモード「N」の場合には、バイ時間ゼロまたは負であり得ることが可能です。これはエラーではない、そのように拒絶されるべきではありません。過去に（バイ・時間）秒 - それは実現-によりタイムが発生したメッセージを示します。 [ここで、「 - （BY-時間）」によって、時間値の算術否定を表す。]任意の要求された配信時間情報に関する情報を保存するようにゼロと負の値が許容されている - 情報配信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.
「R」によって、時間ゼロまたは負のバイモードの場合に構文エラーです。このような場合に、SMTPサーバがコマンドから延長メールに応答して永久的な障害（501）SMTP応答コードを返すべきです。 SMTPサーバーも強化されたエラーコードをサポートしている場合は、[8]、その後、5.5.4の強化エラーコードも返されるべきです。
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サーバがサーバ固有の理由のためにそれを尊重か、受け入れることができない条件があれば一時的または555 SMTP応答である場合、SMTPサーバは、いずれかの455 SMTP応答で応答する必要がある場合状態は永続的です。 SMTPサーバもサポートしている場合に加えて、[8]、適当4.X.X又は5.X.X拡張エラーコードも返されるべきです。
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.
パラメーターして、有効なコマンドを含むFROM拡張メールを受信すると、SMTPサーバと関連するMTAは、以下のサブセクション、セクション4.1.1-4.1.5にあったメッセージを処理しなければなりません。リクエストにより、お届けしてメッセージの処理に応答して生成された配信状態通知は、オプションの到着予定日のDSNフィールドだけでなく、このメモのセクション5で説明した新しい配信・バイ・日のDSNフィールドの両方を含める必要があります。
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.
提供バイ時間に達した前にMTAは、配信不能としてメッセージを返すことがあります。バイ時のメッセージのは、MTAの通常のメッセージの保存期間を延長しないことによって、時間に注意してください。
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はまた、配信ステータス通知SMTPサービス拡張をサポートしている場合は、[5]と「SUCCESS」を含むNOTIFYパラメータが指定された、適切なステータスを持つ「配信」DSNは、[5]あたりとして返さなければなりません。
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は、配信不能としてメッセージが返される場合があります前に、提供・バイ・時間に達しました。ただし、メッセージはまだセクション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".
提供バイ時間が経過していないとのメッセージが永久的な理由で配信できない場合は、SMTPサーバーまたはMTAはありません指定されたパラメータに通知したり、そのためのいずれかで、各受信者のアドレスのための適切なステータスでDSNを「失敗」返さなければなりませんNOTIFYパラメータが「FAILURE」が含まれています。
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は、ステータス5.4.7と「失敗」DSNを発行しなければなりません、パラメータなし指定されたNOTIFYのいずれかで、またはNOTIFYパラメータが「FAILURE」が含まれているため、各受信者のアドレスに対して、「配達時間の期限が切れ」。
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は、ステータス4.4.7と「遅延」DSNを発行しなければなりません、ないパラメータは「DELAY」を含むNOTIFYのための指定されたパラメータまたはNOTIFYのいずれかで、各受信者のアドレスに対して、「配達時間の期限が切れ」。
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.
もしあれば要求によって配信とメッセージは、別のSMTPサーバーとどのような追加措置に中継することができるとき、セクション4.1.4.1と4.1.4.2以下の記述、または取られなければならない必要があります。中継が許可されたときにそれらのセクションで説明したものに加えて、次のようにも観察されなければなりません。
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".
メッセージを拡張することによって配信をサポートするSMTPサーバに中継されている場合は、パラメータで新しい届けバイ時間までの残りの秒数を示すことにより、時間値を指定中継しなければなりません。新しいバイ・時間値は、MAIL FROMコマンドが合理的に可能であるとして中継SMTPクライアントによって送信された時間に近いように計算されなければなりません。配信ごとの時間が経過した場合、バイ時間中継秒送達によって時間経過してもよいかを示す負の値となることに留意されたいです。そのようなケース - 送達バイ時間れるメッセージの中継は、ちょうど到着又は通過した - のみバイモード「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」とのことで、トレースフィールドを持つメッセージを中継する場合には、NOTIFYパラメータまたはNOTIFYパラメータを指定しなかったどちらかの各受信者が値を持たないためにDSNが中継SMTPクライアントによって生成されるべきである「中継しました」 "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.
これらの「中継された」のDSNは関係なく、成功の通知を明示的にNOTIFY = SUCCESSパラメータを指定して要求されたかどうかの生成されることに注意してください。下流SMTPサーバとMTAが依然として[5]をサポートし、このような追加の通知が依然として生じ得るようにすることができる：ここで説明した「中継」のDSNが端末に通知されないことにさらに留意されたいです。
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はバイモード「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を適用すべきです。
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.
バイモード「N」を有するメッセージにかかわらず、それが中継された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サーバーに中継されている場合、中継SMTPクライアントは、NOTIFYパラメータを指定したり、通知しませんでしたどちらかの受信者ごとに「中継」DSNを発行しなければなりませんパラメータは、値「NEVER」を持っていません。さらに、受信者ごとに、次に[5] SMTPサーバは配信ステータス通知のSMTPサービス拡張をサポートするために中継される場合：何のパラメータが供給されたNOTIFY場合、「NOTIFY = FAILURE、DELAYは、」要求されるべきではありません。 NOTIFYパラメータを指定し、値を「絶対」がないない場合はいない既に存在する場合、「遅延」が通知リスト要素の値のリストに追加されるべきです。これは、明示的に[5]のセクション6.2.1の「MUST NOT」の文言（c）をオーバーライドすることに注意してください。
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.
外部メールシステムは、このメモで説明SMTPサービス拡張により、お届けに類似のセマンティクスをサポートしている場合は、そのシステムへの要求によって配信を伝えます。延長することで配信しサポートしていないSMTPサーバーに中継しているかのようそうでない場合は、メッセージを中継します。
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:
配信状態通知（DSN）のフォーマットは、[6]で指定されています。リクエストにより、お届けに応答して生成されたDSNは到着日のDSNフィールドを含める必要があります。このメモはまた、メッセージごとのフィールドは、[6]、新しいDSNフィールドを含むように拡張配信日付によるに、MTAによって計算またはSMTPサーバがDSNを生成するように送達バイ時間を示します。 RFC 822の拡張BNFで次のように[2]、メッセージごとのフィールドは、したがって、拡張されます。
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
メッセージごとのフィールド= [元のエンベロープ-IDフィールドCRLF]報告-MTA-フィールドCRLF [DSN-ゲートウェイフィールドCRLF] [受信から-MTA-フィールドCRLF] [到着日付フィールドCRLF] [届けます-by-日付フィールドCRLF] *（拡張フィールドCRLF）送達日付によるフィールド= "配信日付による" "：" 日時
where date-time is a RFC 822 [2] date-time field as ammended by RFC 1123 [3].
日時は、[3] RFC 1123によって修正されRFC 822 [2]日時フィールドです。
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:
次のサンプルSMTPダイアログで、SMTPクライアントは、メッセージから<eljefe@bigbiz.com> 2分（120秒）以内に<topbanana@other.com>に送達し、それ以外の場合は戻されることを要求します。この要求は、ラインFROM MAIL上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：220 acme.net SMTPサーバここでC：EHLO bigbiz.com S：250-acme.net S：250 DELIVERBY C：MAIL FROM：<eljefe@bigbiz.com>を120 = BY; RS：250 <eljefe @ bigbiz。コム>送信者OK C：RCPT TO：<topbanana@other.com> S：250 <topbanana@wherever.com>受信者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」のオリジナルのために、メッセージは、拡張（セクション4.1.4）で配信をサポートする別のSMTPサーバに中継することができます。メッセージを中継する場合また、リクエストによってお届けは中継されなければなりません。これを念頭に、以下の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：220 mail.other.com ESMTPサーバーご利用のサービスCで：EHLO acme.net S：250-mail.other.com S：250 DELIVERBY 240 C：QUIT
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では、mail.other.comに接続し、EHLOコマンドを発行します。その後、拡張により配信がサポートされていることが、バイモード「R」のためにより時間最小4分（240秒）であることを知ります。この値は、バイ時間メッセージの元を超え、従って、必ずしもによって、残り時間を超えます。中継SMTPサーバーは、このように従わなければならない多くのMXレコードが存在しない場合は、配信不能としてメッセージを返す必要があり、それはどちらかの試みが、他のMXレコードをフォローする必要がある後SMTPセッションを終了しますか。 EHLOコマンドがエラーと会ったか、DELIVERBYキーワードが含まれていなかった場合、同様の挙動が生じるであろう。
Consider instead, the relaying SMTP session:
、代わりに中継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：220 mail.other.com ESMTPサーバーご利用のサービスCで：EHLO acme.net S：250-mail.other.com S：250 DELIVERBY 30 C：FROM MAIL：= 98 BY <eljefe@bigbiz.com>; RS ：250 <eljefe@bigbiz.com>送信者大丈夫C：RCPT TO：<topbanana@other.com> S：250 <topbanana@wherever.com>大丈夫受信者
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クライアントは保存によるモードとコマンドからのメールが中継SMTPクライアント（ACMEから送信されたことおおよその時刻における秒の残数であることが計算によって時間とともにBYパラメータを中継します。受信側のSMTPサーバーへの）ネット（mail.other.com）。 acme.netは、元の送信側クライアントからのラインからのメールを受信し、mail.other.comに要求することによりお届け中継するので、この例では、22秒が経過しました。
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.
そのメールはMXレコードによって指示されているホスト - - 拡張することにより提供するサポート[9]自分のMXホストのすべてがあることを確認する必要がありSMTPサービス拡張により、サービス提供とそのMXレコードを経由して自分のメールを直接使用したいサイト。ことでの配信サポートするSMTPクライアントがすることを配信サポートするものを探している複数のMXホストを試みるべきではありません。
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を導入正常配信待ち時間を認識しないれた宛先ホストによって処理することができるものと実質的に異なる値を提示することは実用的ではありません宛先ホストにリレーメールをホストします。
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".
お届けすることでのImplementionは、メール輸送システムのトレースを可能にします。バイ・トレースフィールド「T」は、明示的にトレースが生成されることを要求します。また、バイ・トレース・フィールドを使用しない場合であっても、粗トレースを順次によって時間値の増加に伴って、搬送システムにそれぞれ一連のメッセージを入力することによって生成することができます。例えば、 "0 = BY; R"、 "= 1 BY; R"、 "= 2であり; R"。プロービング、およびトレースある場合には、他の手段によって達成することができる可視SMTPサーバーを照会、受信調査：バウンスメッセージのヘッダー行を、そのような「トレースルート」としてユーティリティを使用。
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.
SMTPサービス拡張だけでなく、それらに関連のMTAによって配信をサポートするSMTPサーバは要求によって配信のメッセージに特別な処理の優先度を割り当てる必要はありません。彼らが望む場合はもちろん、いくつかのSMTPサーバとのMTAは、そのようにすることができます。また、要求によって配信のメッセージに応答して生成された配信状態通知は、任意の特別な処理を受けるために必要とされません。そのため、このサービスのユーザーは、一般的には、そのメッセージの迅速な処理を期待すべきではありません。また、メッセージを用いて送信されるという理由だけで「BY = 60; R」パラメータは、DSNは、必ずしも送信者に戻す促進されないように、送信者は、任意の指定された時間内に配信失敗を知るであろうことを保証するものではありません。
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.
著者は、この文書の最初の原動力としてだけでなく、その中に具体化の基本的なアイデアの多くを提供するためのキースムーアに感謝したいです。さらにおかげで改善のための彼らのこのドキュメントのレビューや提案のためのネッドフリードとクリス・ニューマンによるものです。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、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"、RFC 2234、1997年11月に。
[3] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[3]ブレーデン、R.、エディタ、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[4] Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[4]ローズ、M.、Stefferud、E.、クロッカー、D.、Klensin、J. N.と解放された、 "SMTPサービス拡張"、STD 10、RFC 1869、1995年11月。
[5] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[5]ムーア、K.、 "配送状態通知のためのSMTPサービス拡張"、RFC 1891、1996年1月。
[6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[6]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 1894、1996年1月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[8] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[8]、N.、RFC 2034、1996年10月 "SMTPサービス拡張は、強化されたエラーコードを返すために、" 解放されました。
[9] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986.
[9]ヤマウズラ、C.、 "メールルーティングとドメインシステム"、STD 14、RFC 974、1986年1月。
Dan Newman Sun Microsystems, Inc. 1050 Lakes Drive, Suite 250 West Covina, CA 91790 USA
ダン・ニューマンサン・マイクロシステムズ株式会社1050湖ドライブ、スイート250ウェストコヴィナ、CA 91790 USA
Phone: +1 626 919 3600 Fax: +1 626 919 3614 EMail: dan.newman@sun.com
電話：+1 626 919 3600ファックス：+1 626 919 3614 Eメール：dan.newman@sun.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。