Translated into Japanese language by weio 日本語訳 weio Email: weio@lycos.jp WWW: http://weio.tripod.co.jp/ 翻訳 2002年 7月22日 translation 22 Jul. 2002 最新版 2002年 8月31日 latest rev. 31 Aug. 2002 この文書はRFC2852を訳者(weio)が個人的な好奇心で適当に翻訳したものです。従って 翻訳の正確さなどは全く保証いたしません。誤訳や根本的な勘違いなどが多く含まれて いるかもしれません。正確な情報が必要な場合は英語原文も別個に入手して、お読みく ださい。この文書によるいかなる損害からも訳者は免責されるものとします。 訳者が訳した部分のみ著作権は訳者に帰属します。ただし文末の著作権全文に従います。 |Network Working Group D. Newman |Request for Comments: 2852 Sun Microsystems |Updates: 1894 June 2000 |Category: Standards Track | | | Deliver By SMTP Service Extension Deliver-By（期限付き配達）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. このメモの位置付け このメモはインターネット共同体のためのインターネット標準トラックプロトコルを示 すものであり、発展のための議論や提案を依頼するものである。このプロトコルの位置 付けや標準化の段階については"Internet Official Protocol Standards"(STD 1)の現 在の版を参照してほしい。このメモの配布は無制限である。 |Copyright Notice | | Copyright (C) The Internet Society (2000). All Rights Reserved. 著作権告知 著作権 (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クライアントから依頼できるメカニズムを定義する。 そのような要求をするクライアントは、もし指定された期間以内にメッセージが配達で きないならば発生するメッセージの扱いも指定する：メッセージも、さらなる処理なし で配達不能として戻されるか、または"delayed"配達状態通知(DSN)[6]（訳注：文末の 参考文献[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 | | | |Newman Standards Track [Page 1] | |RFC 2852 Deliver By SMTP Service Extension June 2000 | | | 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. このメカニズムの典型的な用法は、差出人または受取人に意味がある、未来のある時を 越えるメッセージの配達を防止する必要があるが、メッセージを操作しているMTAsには 知られていない場合である。例えば、差出人は、メッセージがページとして配達される ことを知っているかもしれないが、営業時間の後に受取人にページを付けることを保証 するメッセージは十分に重要であると考えないかもしれない。その場合に17時00分以後 は配達が試みられないようにメッセージは刻印され得る。差出人が配達遅延を警告され ることを望む時には、別の一般的な用法が生じる。この場合において、差出人はメッ セージが、もし（言うならば）30分以内に配達されないならば"delayed"DSNが生成され るが配達の試みはそれにもかかわらず続けられるように刻印できる。この場合、差出人 は配達の問題を知りたくなった時のための希望を表現することが許されている。 |1. Definitions | | 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. 1. 定義 この文書を通じて、「配達」と言う用語はメッセージをメッセージ輸送エージェント （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」「REQUIRED」「SHOULD」および「SHOULD NOT」という キーワードは、RFC2119[7]において説明されているように解釈される必要がある。 |2. Framework for the Deliver By SMTP service extension | | The Deliver By SMTP service extension uses the SMTP service extension | mechanism described in [4]. The following SMTP service extension is | therefore defined: 2. SMTPサービス拡張による配達のための枠組 このSMTPサービス拡張による配達では、[4]において説明されたSMTPサービス拡張メカ ニズムが使われる。従って、以下のSMTPサービス拡張が定義される： | (1) The name of the SMTP service extension is "Deliver By". (1) SMTPサービス拡張の名前は"Deliver By"である。 | (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つのオプション"min-by-time"が指定される。将来の文書は付加的なオプ ションを指定することによりこの指定を拡張できる。"min-by-time"はセクション4に従 って"R"の"by-mode"が指定される時にサーバーが受け入れる固定された最小の"by-mode "を示す固定された整数である。 | 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 | | | deliverby-param = min-by-time *( ',' extension-token ) | min-by-time = [1*9DIGIT] | extension-token = 1* | SP = | COMMA = | | If the parameter is omitted, no information is conveyed about | the server's fixed minimum by-time. もしパラメータが省略されるならば、サーバーの固定された最小の"by-time"について の情報は、全く伝えられない。 | (4) One optional parameter using the keyword "BY" is added to the | MAIL FROM command. (4) キーワード"BY"を使う1つのオプションのパラメータが"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 FROM"コマンドラインの最大の長さはBYキーワードとその値の可能な付加に よって17文字である。 | (6) No additional SMTP verbs are defined by this extension. (6) 付加的なSMTP動詞はこの拡張により全く定義されない。 |3. The Deliver By SMTP service extension | | 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. 3. SMTPサービス拡張による配達 SMTPサービス拡張による配達の使用を望むSMTPクライアントは、SMTPセッションを始め るため、かつSMTPサーバーがサービス拡張をサポートするかどうかを判断するためにEH LOコマンドを発行できる。もしサーバーがコード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応答のDELIVERBYキーワード値に続いているならば、 そのパラメータは、セクション4で説明されるように"R"の"by-mode"が拡張された"MAIL FROM"コマンドによって指定される時に"by-time"を許す最小の値を示す。クライアン トからの"R"の"by-mode"と"by-time"を厳密にこの限界("min-by-time")より小さく指定 するいかなる試みも固定失敗（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 |Newman Standards Track [Page 3] | |RFC 2852 Deliver By SMTP Service Extension June 2000 | | | 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で説明され る"MAIL FROM"コマンドの拡張版を受け入れる。サーバーによってサポートされる時に は、指定された期間中メッセージが配達されるように依頼するために、SMTPクライアン トは（[1]において説明された"MAIL FROM"コマンドの代わりに）拡張された"MAIL FROM "コマンドを用いることができる。サーバーが、要求に敬意を払わないと判断するなら ば適切なエラーコードを返すであろう。"RCPT TO"コマンドによる受取人のアドレスの 提示またはメッセージデータのドット(.)コマンドによる転送の完成まで、これがサー バーに明白ではないかもしれないことに注意せよ。そのようなものとして、サーバーは、 クライアントに"MAIL FROM"コマンドに成功応答を送っても、後の"RCPT TO"、DATA、ま たはドットコマンドへはエラー応答を返すことができる。 |4. The extended MAIL FROM command | | 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. 4. 拡張された"MAIL FROM"コマンド SMTPクライアントが、SMTPサーバーにメッセージが指定された期間内に配達されるか （そうでなければ期間内にメッセージが配達不能であることがはっきりしたらどんな行 動を取るべきか）を知らせることを望む時は、拡張された"MAIL FROM"コマンドを発行 する。アドレスの後にBYパラメーターが出現する以外、拡張された"MAIL FROM"コマン ドは、RFC821[1]において定義された"MAIL FROM"コマンドと同一である。 | 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キーワードは"B Y"であり、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" | 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 | | -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. "BY"esmtpキーワードは関連したesmtp値を持たなければならないことに注意せよ。"by- time"はメッセージが配達されるべき秒数の10進の表現であり、範囲を持つ -999999999秒 <= by-time <= +999999999秒 従って、未来と過去に、約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で説明されるように"by-mode"は"by-time"秒以内にメッセージを送るこ とができないために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. "by-time"がデルタ時間であることに注意せよ：メッセージを配達する中の秒数。この デルタ時間はMTAの正常な保持期間を配達不能のメッセージのために延長せず"deliver after"時間でもない。 | 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. クライアントとサーバーの間のシステム時計の違いに関連した問題を防止するためにデ ルタ時間が使われる。パラメータごとに有効な受取側のサーバーが"by-time"を、"deli ver-by-time"と呼ばれる現地特定の絶対時間に変換することが期待される。 |Newman Standards Track [Page 4] | |RFC 2852 Deliver By SMTP Service Extension June 2000 | | | 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. これは、受け取りに現在の現地特定の時間の"by-time"を付加する、従って現地特定の 絶対時間での到着時には"by-time"の計算の合図に依存する未来または過去の"by-time" 秒となる。その後メッセージは"deliver-by-time"によって配達される。差出人のクラ イアントと受取側サーバーは"MAIL FROM"コマンドの伝達時間は瞬時であると仮定して いるであろう。明らかにそうではなく、かつネットワークの遅延時間はエラーを引き起 こす、この性質は効果的な"by-time"をわずかに拡張するであろう。メッセージがより 多くの段階を経るにつれて、この遅延時間により引き起こされるエラーは、その累積す る性質のために大きな影響が宣言されるであろう。 | 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-mode"の場合には"by-time"は0または負であるかもしれない可能性がある。こ れはエラーではなく、そのようなものとして拒絶されるべきではない。それは過去の- (by-time)秒に"deliver-by-time"が起こったメッセージを示す［ここでは"-(by-time)" は"by-time"値の計算の否定を表している］。どのような要求された納期情報でも保存 するために0および負の値が許される。 - 配達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"の"by-mode"の場合には0または負の"by-time"は文法エラーである。そのような場合、 拡張された"MAIL FROM"コマンドに対して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"が有効な"by-time"指定だが、SMTPサーバーがサーバー由来の理由で敬意 を払って受け取ることができないならば、SMTPサーバーは、もし条件が一時的ならば45 5のSMTP応答、またはもし条件が永久ならば555のSMTP応答のどちらかで反応すべきであ る。加えて、もしSMTPサーバーが[8]もサポートするならば、適当な4.X.X/5.X.X拡張エ ラーコードも返すべきである。 |4.1. Server behavior upon receipt of the extended MAIL FROM command | | 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. 4.1. 拡張された"MAIL FROM"コマンドの受け取りでのサーバーの挙動 有効なBYパラメータを含む拡張された"MAIL FROM"コマンドの受け取りでは、SMTPサー バーと関連したMTAは以下の節（セクション4.1.1-4.1.5）に従うメッセージが扱わなけ ればならない。要求付き配達によるメッセージを処理することに対して生成する配達状 態通知は、"Arrival-Date"DSNフィールドだけでなく、このメモのセクション5で説明さ れる新しい"Deliver-By-Date"DSNフィールドの両方のオプションの到着の日付を含むは ずである。 |Newman Standards Track [Page 5] | |RFC 2852 Deliver By SMTP Service Extension June 2000 | | | 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. "by-time"はメッセージの"by-time"がMTAの正常なメッセージ保持期間を延長しないこ とを注意する：MTAは"deliver-by-time"に達する前に配達不能としてメッセージを返し てもよい。 |4.1.1. Successful delivery | | 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]. もし"deliver-by-time"以前にメッセージが配達されるならば、特別な行動は全く取ら れる必要がない。もしSMTPサーバーまたはMTAが、配達状態通知SMTPサービス拡張[5]も サポートし、SUCCESSを含むNOTIFYパラメータが指定されたならば、[5]に従って、適切 な状態を持つ"delivered"DSNが戻されなければならない。 |4.1.2. Unsuccessful delivery; deliver-by-time not yet reached | | 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. 4.1.2. 不成功な配達；まだ"deliver-by-time"に達していない もし"deliver-by-time"がいまだ過ぎておらず、メッセージが一時的な理由のために配 達不能であると判明したならば、SMTPサーバーまたはMTAは、サイトのメッセージ操作 方針に従って、配達／中継の試みを続けるべきである。もしMTAのメッセージ保持期間 が"by-time"より短ければ、MTAは"deliver-by-time"以前に配達不能としてメッセージ を返してもよい。しかしながら、依然としてメッセージはセクション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". もし"deliver-by-time"がいまだ過ぎておらず、永久的な理由のためにメッセージが配 達できないならば、SMTPサーバーまたはMTAは、受取アドレスごとに適切な状態の指定 されたNOTIFYパラメータを全く含まないかFAILUREを含むNOTIFYパラメータで"failed"D SNを返さなければならない。 |4.1.3. Time has expired; deliver-by-time reached or passed | | 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". 4.1.3. 時間は満了した；"deliver-by-time"に達したか、または過ぎた。 もし"deliver-by-time"および"R"の"by-mode"で指定されている以前にメッセージが配 達／中継されないならば、より一層の配達の試みはメッセージについて全くされないで あろう。サーバーまたはMTAは受取アドレスごとに適切な状態の、指定されたNOTIFYパ ラメータを全く含まないかFAILUREを含むNOTIFYパラメータで、ステータス5.4.7と「配 達時間満了」と共に"failed"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". もし"deliver-by-time"および"N"の"by-mode"で指定されている以前にメッセージが配 達／中継されないならば、SMTPサーバーまたはMTAは、サイトのメッセージ操作方針に 従って、配達／中継の試みを続けるべきである。加えて、サーバーまたはMTAは、受取 アドレスごとに適切な状態の、指定されたNOTIFYパラメータを全く含まないかDELAYを 含むNOTIFYパラメータで、ステータス4.4.7と「配達時間満了」と共に"delayed"DSNを 発行しなければならない。 |Newman Standards Track [Page 6] | |RFC 2852 Deliver By SMTP Service Extension June 2000 | | |4.1.4. Relaying to another SMTP server | | 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. 別のSMTPサーバーへの中継 下のセクション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サーバーに中継されるならば、新 しいBYパラメータは、"deliver-by-time"までに残る秒数を示す"by-time"値を指定して 中継しなければならない。新しい"by-time"値は可能な限り"MAIL FROM"コマンドが中継 するSMTPクライアントにより伝達される時間の近くで計算されるべきである。もし"del iver-by-time"が過ぎているならば、中継された"by-time"は"deliver-by-time"以来経 過した秒数を示す方法としての負の値であるだろうことに注意せよ。そのような場合 - "deliver-by-time"にたった今達した／過ぎた - のメッセージの中継は"N"の"by-mode "を持っているメッセージについてのみ発生する可能性がある。 | 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"を持つ"by-trace"フィールドを持つメッセージが中継される時には、NOTIFYパラ メータが指定されていないか、またはNOTIFYパラメータが値NEVERを持っていないかの、 どちらかの個々の受取人には、中継するSMTPクライアントによる"relayed"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. 成功通知がNOTIFY=SUCCESSパラメータによって明示的に要求されたかどうかに関わらず、 これらの"relayed"DSNsが生成されることに注意せよ。ここで議論される"relayed"DSNs は最終の通知からは離れたものであることに注意せよ：下りのSMTPサーバーとMTAsは依 然として[5]をサポートすることができて、そのような付加的な通知が依然として結果 となるかもしれない。 |4.1.4.1. Relaying a message with a by-mode of "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. 4.1.4.1. "R"の"by-mode"を持つメッセージの中継 "R"の"by-mode"が指定されたメッセージはSMTPサービス拡張による配達をサポートしな いSMTPサーバーに中継してはならない。さらに、中継されるサーバーが配達された時に メッセージに残された時間より大きい修正された最小の"by-time"を持ってはならない。 修正された最小の"by-time"は、セクション2で議論されたオプションの"deliverby-par am"のために表現される。 | 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 | | |4.1.4.2. Relaying a message with a by-mode of "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. 4.1.4.2. "N"の"by-mode"を持つメッセージの中継 それが中継されるSMTPサーバーが拡張による配達をサポートするかどうかに関わらず、 "N"の"by-mode"を持つメッセージは、別のサーバーに中継できる。 | 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]. もし"deliver-by-time"以前にメッセージが拡張による配達をサポートしないSMTPサー バーに中継されるならば、NOTIFYパラメータが指定されていないか、またはNOTIFYパラ メータが値NEVERを持っていないかの、どちらかの個々の受取人に、中継するSMTPクラ イアントは"relayed"DSNを発行しなければならない。1人のさらに、SMTPサーバーが配 達状態通知SMTPサービス拡張[5]をサポートするために中継されるならば、個々の受取 人のためには：もしNOTIFYパラメータが全く供給されなかったならば、"NOTIFY=FAILUR E,DELAY"が要求されるべきである；もしNOTIFYパラメータが指定されたがNEVER値を持 たないならば、DELAYがすでに存在しなければ通知リスト要素値のリストに加えられる べきである。これは[5]のセクション6.2.1(c)の"MUST NOT"表現を明らかに上書きする ことに注意せよ。 |4.1.5. Relaying to a foreign mail system | | 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. 4.1.5. 他のメールシステムへの中継 もし他のメールシステムが、このメモにおいて説明されたSMTPサービス拡張による配達 と同様な意味論をサポートするならば、そのシステムに応じて要求付き配達を伝えよ。 さもなければ、拡張による配達をサポートしないSMTPサーバーへ中継するかのように、 メッセージを中継せよ。 |5. Delivery status notifications and extension | | 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: | | 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 5. 配達状態の通知と拡張 配達状態通知(DSNs)の書式は[6]において指定される。要求付き配達に対して生成され たDSNsは"Arrival-Date"DSNフィールドを含むべきである。このメモはまた、[6]のメッ セージごとのフィールドを、DSNを生成するMTAまたはSMTPサーバーにより計算される"d eliver-by-time"を示す、新しい"Deliver-By-Date"DSNフィールドを含むように拡張す る。 従って、RFC822[2]の拡張BNFで、メッセージごとのフィールドは次の通りに拡張 される： |Newman Standards Track [Page 8] | |RFC 2852 Deliver By SMTP Service Extension June 2000 | | | where date-time is a RFC 822 [2] date-time field as ammended by RFC | 1123 [3]. "date-time"はRFC1123[3]によって修正されたRFC822[2]"date-time"フィールドである。 |6. Examples | | In the following sample SMTP dialog, the SMTP client requests that a | message from be delivered to | 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: | | S: 220 acme.net SMTP server here | C: EHLO bigbiz.com | S: 250-acme.net | S: 250 DELIVERBY | C: MAIL FROM: BY=120;R | S: 250 sender ok | C: RCPT TO: | S: 250 recipient ok 6. 例 以下のサンプルSMTP対話において、SMTPクライアントはからのメ ッセージが2分（120秒）以内にに配達されるか、さもなければ 戻されるように依頼する。この要求は、下に示されるように"BY=120；R"の"MAIL FROM" 行におけるBYパラメータの形を取る： | 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: | | 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 上記の例の受取側SMTPサーバーがメッセージを別のSMTPサーバー(mail.other.com)に中 継する必要があることを想像せよ。元の"by-mode"が"R"のため、メッセージは拡張によ る配達をサポートする別のSMTPサーバーに中継できるだけである（セクション4.1.4）。 さらに、メッセージを中継する時には、要求付き配達も中継されなければならない。こ れを踏まえて、以下のSMTP対話を考慮せよ： | 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"の"by-mode" のための最小の"by-time"は4分（240秒）であることを知る。この値はメッセージの元 の"by-time"を越え、従って、必ず残りの"by-time"を越える。従って、中継SMTPサー バーはSMTPセッションを終える。その後、続く他のMXレコードに試みなければならない が、それが無くなれば、配達不能としてメッセージを戻さなければならない。もしEHLO コマンドがエラーに直面したか、またはDELIVERBYキーワードを含まないならば、同様 な行動が結果として生じるであろう。 | Consider instead, the relaying SMTP session: 代わりに考慮せよ、中継SMTPセッションは： |Newman Standards Track [Page 9] | |RFC 2852 Deliver By SMTP Service Extension June 2000 | | | 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: BY=98;R | S: 250 Sender okay | C: RCPT TO: | S: 250 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クライアントは、保存された"by-mode"、および"MAIL FROM"コマン ドが中継SMTPクライアント(acme.net)から受取側SMTPサーバー(mail.other.com)に送ら れる大体の時刻から計算された残り秒数である"by-time"を持つBYパラメータを中継す る。この例では、acme.netが元の送信クライアントから"MAIL FROM"行を受け取ってか ら、要求付き配達をmail.other.comに中継するまでに、22秒が経過する。 |7. MX based relaying considerations | | 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. 7. MXに基礎を置く中継の考慮 SMTPサービス拡張による配達を使用することを望み、かつ拡張による配達をMXホスト （それらのメールがMXレコードにより宛先とされるホスト）がサポートすることを保証 する必要性からMXレコード[9]経由でメールを直送するサイト。「による配達」をサ ポートする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コマンドに対してそれらが示す"min-by-time"値に慎重に注意するべき である。それは、(1)それを中継する宛先ホストにより扱われ得るものと大幅に違う値 を示すこと、(2)MXホストが宛先ホストにメールを中継する時に、紹介された正常な配 達遅延時間を認識しないことのどちらも、MXホストが値を出現させるためには現実的で ない。 |8. Security Considerations | | 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". 8. セキュリティ考慮 「による配達」の実装はメール輸送システムの追跡を許す。"by-trace"フィールド"T" は足跡が生成されるように明示的に依頼する。さらに、"by-trace"フィールドが使われ ない時でさえ、天然の跡は、それぞれ連続して増加する"by-time"値を持つ（例えば"BY =0;R","BY=1;R","BY=2;R"）一連のメッセージを輸送システムに入力することによって 生成されるかもしれない。精査およびある場合には追跡も他の方法で遂行できる：可視 のSMTPサーバーに問いかける、メッセージ中の"Received:"ヘッダ行を調査する、trace route等のユーティリティを使う。 |Newman Standards Track [Page 10] | |RFC 2852 Deliver By SMTP Service Extension June 2000 | | |9. Other Considerations | | 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. 9. 他の考慮 SMTPサービス拡張による配達をサポートするSMTPサーバーと関連したMTAsは、少しの特 別な処理優先度も要求付き配達のメッセージに割り当てることを要求されない。もちろ ん、いくつかのSMTPサーバーとMTAsは、もしそれらが望むならばそうするであろう。さ らに、要求付き配達のメッセージに対して生成される配達状態通知は、いかなる特別な 処理も受け取るために必要としない。その結果、このサービスのユーザーは、一般に、 彼らのメッセージに優先的な処理を期待すべきではない。さらに、メッセージが"BY=6 0;R"パラメータで送られることは、どのような指定された時間内の配達失敗でも、必ず しもDSNを差出人に戻すことが促進されることを保証するわけではないと知るであろう。 |10. Acknowledgments | | 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. 10. 謝辞 著者は、この文書中で具体的に示された基礎的なアイデアだけでなく、この文書の最初 の刺激の多くを提供したことをKeith Mooreに感謝することを望む。さらに、この文書 の批評と改良のための提案を行ったNed FreedとChris Newmanに感謝する。 |Newman Standards Track [Page 11] | |RFC 2852 Deliver By SMTP Service Extension June 2000 | | |11. References | | [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, | August 1982. 11. 参考文献 [1] Postel,J.,「簡潔なメール転送手順」,STD10,RFC821,1982年8月 | [2] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax | Specifications: ABNF", RFC 2234, November 1997. [2] Crocker, D., Editor, and P. Overell,「構文仕様の拡張BNF：ABNF」RFC2234,199 7年11月 | [3] Braden, R., Editor, "Requirements for Internet Hosts -- | Application and Support", STD 3, RFC 1123, October 1989. [3] Braden,R., Editor,「インターネットホストへの要求 - アプリケーションとサ ポート」,STD3,RFC1123,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サー ビス拡張」,STD10,RFC1869,1995年11月 | [5] Moore, K., "SMTP Service Extension for Delivery Status | Notifications", RFC 1891, January 1996. [5] Moore, K.,「配達状況通知のためのSMTPサービス拡張」,RFC1891,1996年1月 | [6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for | Delivery Status Notifications", RFC 1894, January 1996. [6] Moore, K., and G. Vaudreuil,「配達状態通知のための拡張可能なフォーマット」, RFC1894,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内で使われる要求レベル表示のキーワード」,BCP14,RFC2119,19 97年3月 | [8] Freed, N., "SMTP Service Extension for Returning Enhanced Error | Codes", RFC 2034, October 1996. [8] Freed, N.,「拡張エラーコードのためのSMTPサービス拡張」,RFC2034,1996年10月 | [9] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC | 974, January 1986. [9] Partridge, C.,「メールルーティングとドメインシステム 」,STD14,RFC974,1986 年1月 |12. Author's Address | | 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 13. 著者の連絡先 Dan Newman サン・マイクロシステムズ　社 |Newman Standards Track [Page 12] | |RFC 2852 Deliver By SMTP Service Extension June 2000 | | |13. Full Copyright Statement | | Copyright (C) The Internet Society (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. 14. 著作権全文 著作権 (C) The Internet Society (2000) 全ての権利を有す この文書とその翻訳は、複製し他人に配布することができる、更に、コメント、あるい は説明又はその実装の補助となる関連作業について、その全て又は一部にかかわらず、 すべてのそのような複製物や関連する作業に、上の著作権表示と、この節を含めていれ ば、いかなる制約もなく、作成、複製、発表、及び配布することができる。しかしなが ら、この文書自体に関して、インターネット標準化プロセスに定義されている著作権の 手続きによってインターネット標準の開発の提案に必要とされる場合や、英語以外の言 語に翻訳する必要がある場合を除いて、著作権表示や The Internet Society あるいは 他のインターネット団体へのリファレンスを削除するような変更をしてはならない。 | The limited permissions granted above are perpetual and will not be | revoked by the Internet Society or its successors or assigns. 上で認めた制限された許諾は永続的であり、The Internet Society 又はその継承者や 譲渡者によって取り消されない。 | 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. この文書とここに含まれた情報は「そのまま(AS IS)」をベースに、提供され、THE INT ERNET SOCIETY 及び THE INTERNET ENGINEERING TASK FORCE は、この中の情報の使用 がいかなる権利も侵害していないことだけでなく、 商用利用及び特定用途のいかなる 暗黙的な保障を含めて、明示的に又は暗黙的に、全ての保障を放棄する。 |Acknowledgement | | Funding for the RFC Editor function is currently provided by the | Internet Society. 謝辞 RFC編集機能への資金は現在インターネット学会により提供されている。 |Newman Standards Track [Page 13] | （訳注：終）