[要約] RFC 2852は、SMTPサービス拡張によるメールの配信を扱っており、要約すると以下のようになります。1. RFC 2852は、SMTPサービス拡張を使用してメールの配信を改善するためのガイドラインを提供します。 2. このRFCの目的は、SMTPサービスの拡張を通じて、メールの配信の信頼性と効率を向上させることです。 3. RFC 2852は、SMTPサービスの拡張に関する標準化と実装の一貫性を確保するために作成されました。
Network Working Group D. Newman
Request for Comments: 2852 Sun Microsystems
Updates: 1894 June 2000
Category: Standards Track
Deliver By SMTP Service Extension
SMTPサービス拡張機能によって配信されます
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.
Copyright（c）The Internet Society（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 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 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.
このメカニズムの典型的な使用法は、送信者または受信者への将来の重要な時期を超えてメッセージの配信を防ぐことですが、メッセージを処理するMTAでは知られていません。たとえば、送信者は、メッセージがページとして配信されることを知っているかもしれませんが、営業時間後に受信者のページングを保証するためにメッセージが十分に重要であるとは考えていません。その場合、メッセージは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].
このドキュメントの「必須」、「そうでなければならない」、「そうでなければ」、「すべきではない」は、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キーワード値では、1つのオプションパラメーターが許可されています。オプションのパラメーターは、提供される場合、オプションのコンマ分離リストです。このドキュメントでは、1つのオプションのみが1つのオプションで指定されています。将来のドキュメントは、追加のオプションを指定することにより、この仕様を拡張する場合があります。最小時間は、セクション4に従って「R」のバイモードが指定されている場合にサーバーが受け入れる固定最小時間を示す固定整数です。
The syntax of the optional parameter is as follows, using the augmented BNF notation of RFC 2234 [2]:
オプションのパラメーターの構文は、RFC 2234の拡張BNF表記を使用して、次のとおりです[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)>
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) コマンドラインからのメールの最大長さは、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クライアントは、EHLOコマンドを発行してSMTPセッションを開始し、SMTPサーバーがサービス拡張機能をサポートするかどうかを判断することができます。サーバーがコード250でEhloコマンドに応答し、応答に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応答の配信キーワード値に従う場合、そのパラメーターは、セクション4で説明されているように、「R」のバイモードがコマンドからの拡張メールで指定されている場合に許可される最小値を示します。クライアントが「R」のバイモードを指定して、この制限よりも厳密に少ない時間を指定しようとします。
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サーバーは、セクション4で説明されているコマンドからの拡張バージョンのメールを受け入れます。サーバーがサポートすると、SMTPクライアントはコマンドから拡張メールを使用できます（コマンドからのメールの代わりに）[1]で）は、指定された期間内にメッセージを配信するように要求します。その後、リクエストを尊重できないと判断した場合、サーバーは適切なエラーコードを返すことができます。これは、RCPTを使用してRCPTにアドレス指定するか、DOT（。）コマンドによるメッセージデータの転送を完了するか、受信者のプレゼンテーションをrcptにアドレス指定するまで、サーバーには明らかではないことに注意してください。そのため、サーバーはクライアントにコマンドからのメールへの成功応答を送信することができます。
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クライアントがSMTPサーバーに指定された期間内にメッセージを配信し、その期間内にメッセージが統合不可能であることが証明された場合に、どのアクションが配信されるかを通知したい場合に発行されます。コマンドからの拡張メールは、RFC 821 [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-KeyWordは「by」であり、ESMTP値の構文は、以下に示す副価値の構文によって与えられます。RFC 2234 [2]の拡張BNF [2]では、by esmtp-parameterの構文は
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"
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-keywordには関連するESMTP値が必要であることに注意してください。時間は、メッセージを配信し、範囲を持つ秒数の小数の表現です
-999,999,999 seconds <= by-time <= +999,999,999 seconds
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.
これは、現在のロケール固有の時間に領収書時に順番を追加し、それによって、時刻の算術的な兆候に応じて、将来または過去の時間秒であるロケール固有の絶対時間に到達することによって行われます。メッセージは、配信によって配信されることになります。送信クライアントと受信サーバーは、コマンドからのメールの送信時間を瞬時に想定する必要があります。明らかに、それはそうではなく、ネットワークレイテンシはエラーを導入します。その性質は、時間ごとにわずかに拡張することです。メッセージがより多くのホップがかかるほど、このレイテンシ誘導エラーの累積的な性質により、効果がより顕著になります。
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-time）"は、時間の値の算術否定を表します。]ゼロと負の値は、要求された配達時間情報に関する情報を保持するために許可されます - 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.
by-timeが有効な時間仕様であるが、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.
パラメーターによる有効なコマンドから拡張メールを受け取ると、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]もサポートし、「成功」を含む通知パラメーターが指定された場合、[5]に従って適切なステータスの「配信された」DSNを返す必要があります。
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パラメーターには「障害」が含まれます。
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".
配信前にメッセージが配信または中継されておらず、「R」のバイモードが指定された場合、メッセージに対してさらなる配信の試行は行われません。サーバーまたはMTAは、ステータス5.4.7で「失敗した」DSNを発行する必要があります。「配信時間」は、通知パラメーターが指定されていないか、通知パラメーターに「障害」を含む通知パラメーターが含まれている各受信者アドレスに対して、「失敗」を発行する必要があります。
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".
配信前にメッセージが配信またはリレーされていない場合、「n」のバイモードが指定された場合、サーバーまたはMTAは、サイトのメッセージ処理ポリシーを使用してメッセージの配信またはリレーを継続する必要があります。さらに、サーバーまたはMTAは、ステータス4.4.7で「遅延」DSNを発行する必要があります。「配信時間」は、通知パラメーターが指定されていないか、通知パラメーターに「遅延」を含む通知パラメーターが含まれていない各受信者アドレスについてです。
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は、リクエストによる配信のメッセージが別の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".
メッセージが拡張による配信をサポートするSMTPサーバーに中継されている場合、パラメーターごとに新しいバイタイム値を指定して、残りの秒数を示す時間を指定する必要があります。新しい時間の値は、コマンドからのメールが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」を持つバイトレースフィールドを持つメッセージが中継される場合、「リレー」DSNは、通知パラメーターを指定していないか、通知パラメーターが値を持っていない各受信者の中継者によって生成する必要があります。"一度もない"。
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パラメーターで成功通知が明示的に要求されたかどうかに関係なく生成されることに注意してください。さらに、ここで説明する「中継」DSNは端末通知ではないことに注意してください。ダウンストリームSMTPサーバーとMTAは引き続き[5]をサポートする可能性があるため、追加の通知が引き続き発生する可能性があります。
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.
「R」のバイモードが指定されたメッセージは、SMTPサービス拡張機能による配信をサポートしないSMTPサーバーに中継する必要はありません。さらに、中継されるサーバーには、メッセージが配信される時間よりも大きい固定最小時間を持たない必要があります。固定最小時間隔は、セクション2で説明したオプションの配信パラムで表されます。
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クライアントは、通知パラメーターまたは通知を指定しなかった各受信者に「リレーした」DSNを発行する必要がありますパラメーターには「Never」値がありません。さらに、配信ステータス通知SMTPサービスエクステンション[5]をサポートするようにSMTPサーバーが中継されている場合、各受信者について：通知パラメーターが提供されなかった場合、「Notify =障害、遅延」を要求する必要があります。notifyパラメーターが指定されており、値「never」値がない場合、「遅延」を既に存在していない場合はnotify-list-element値のリストに追加する必要があります。これは、[5]のセクション6.2.1（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.
Foreign Mail Systemがこのメモに記載されている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:
配信ステータス通知（DSNS）の形式は[6]で指定されています。リクエストごとに配信に応じて生成されたDSNSには、到着日DSNフィールドを含める必要があります。また、このメモは[6]のメッセージごとのフィールドを拡張して、DSNを生成するMTAまたはSMTPサーバーによって計算された配信を示す、新しいDSNフィールド、配信、納期を示します。RFC 822 [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
where date-time is a RFC 822 [2] date-time field as ammended by RFC 1123 [3].
ここで、日付時間はRFC 1123 [3]によって改善された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>に配信し、それ以外の場合は返品することを要求します。このリクエストは、以下に示すように、「by = 120; r」という行からメールのbyパラメーターの形式を取得します。
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
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）。さらに、メッセージを中継する場合、リクエストごとに配信を中継する必要があります。これを念頭に置いて、次の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
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サーバーを中継すると、SMTPセッションが終了し、その後、他のMXレコードに従うことを試みる必要があります。または、従うべきMXレコードがもうない場合は、配信不可能にメッセージを返す必要があります。Ehloコマンドにエラーが満たされた場合、またはDervirybyキーワードが含まれていない場合、同様の動作が生じます。
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
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から送信される近似時間で残りの秒数に計算されます。Net）受信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.
SMTPサービスエクステンションによる配信を使用し、MXレコードを介してメールを指示するサイト[9]は、MXレコードがメールを送信するすべての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）リレーする宛先ホストが処理できるものとは大幅に異なる値を提示することは実用的ではありません。ホストは、宛先ホストにリレーします。
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".
配信の実装により、メール輸送システムのトレースが可能になります。バイトレースフィールド「t」は、トレースを生成することを明示的に要求します。さらに、バイトレースフィールドを使用していない場合でも、輸送システムに一連のメッセージを入力することで粗いトレースが生成される場合があります。例： "by = 0; r"、 "by = 1; r"、 "by = 2; r"。プロービング、場合によっては、他の手段を通じて実現できます。可視SMTPサーバーのクエリ、受信した調査の調査：バウンスされたメッセージのヘッダーライン、および「Traceroute」などのユーティリティを使用します。
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.
著者は、キース・ムーアに、この文書の最初の推進力の多くとその中に具体化された基本的なアイデアを提供してくれたことに感謝したいと考えています。Ned FreedとChris Newmanのこの文書のレビューと改善の提案に感謝します。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[2] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker、D.、Editor、および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] Braden、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] Rose、M.、Stefferud、E.、Crocker、D.、Klensin、J。and N. Freed、「SMTP Service Extensions」、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] Moore、K。およびG. Vaudreuil、「配信ステータス通知のための拡張可能なメッセージ形式」、RFC 1894、1996年1月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[8] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[8] Freed、N。、「強化されたエラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[9] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986.
[9] Partridge、C。、「メールルーティングとドメインシステム」、STD 14、RFC 974、1986年1月。
Dan Newman Sun Microsystems, Inc. 1050 Lakes Drive, Suite 250 West Covina, CA 91790 USA
Dan Newman Sun Microsystems、Inc。1050 Lakes Drive、Suite 250 West Covina、CA 91790 USA
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: dan.newman@sun.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。