[要約] RFC 4865は、SMTP Submission Service Extension for Future Message Releaseに関する仕様書です。このRFCの目的は、SMTPサーバーが将来のメッセージリリースをサポートするための拡張機能を提供することです。
Network Working Group G. White
Request for Comments: 4865 Independent
Updates: 3463, 3464 G. Vaudreuil
Category: Standards Track Alcatel-Lucent
May 2007
SMTP Submission Service Extension for Future Message Release
将来のメッセージリリースのための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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time.
このメモは、クライアントが配信のためにリリースされる将来の時間を示すためのSMTP提出プロトコルの拡張機能を定義します。この拡張機能により、クライアントは、将来の任命された時間までキューに保持されるべきメッセージにサーバーベースのストレージを使用できます。これは、ローカルストレージがない場合や、指定された時間に配信のメッセージをリリースできないクライアントに役立ちます。
There is a widely used feature within the voice messaging community to compose and send a message for delivery in the future. This is useful for sending announcements to be heard at the beginning of a work day, to send birthday greetings a day or so ahead, or to use as a lightweight facility to build a personal reminder service.
Voice Messagingコミュニティ内には、将来の配信のメッセージを作成して送信するための広く使用されている機能があります。これは、就業日の初めに聞かれるアナウンスを送信したり、誕生日の挨拶を1日ほど先に送ったり、軽量の施設として使用して個人的なリマインダーサービスを構築するのに役立ちます。
This extension uses the SMTP submission protocol [n3] to allow a client, when submitting a message, to indicate a future time for the message to be released for delivery.
この拡張機能は、SMTP提出プロトコル[N3]を使用して、メッセージを送信するときにクライアントが配信のためにリリースされる将来の時間を示すことを許可します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [n1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[n1]で説明されているように解釈される。
The Future Message Release service extension for SMTP submission uses the SMTP service extension mechanism [n4] to extend the SMTP submission protocol [n3]. The following SMTP submission service extension is hereby defined:
SMTP提出の将来のメッセージリリースサービス拡張機能は、SMTPサービス拡張メカニズム[N4]を使用してSMTP提出プロトコル[N3]を拡張します。以下のSMTP提出サービス拡張機能は、次のように定義されています。
The name of the SMTP submission service extension is "Future Message Release".
SMTP提出サービス拡張機能の名前は「将来のメッセージリリース」です。
1) The Extended Hello (EHLO) keyword associated with this service extension is "FUTURERELEASE".
1) このサービス拡張機能に関連付けられている拡張Hello（EHLO）キーワードは「FuturerElease」です。
2) Two required parameters, the max-future-release-interval and the max-future-release-date-time, are combined with the EHLO keyword in the manner specified in [n4].
2) 必要な2つのパラメーター、Max-Future-release-intervalとMax-Future-release-date-timeは、[N4]で指定された方法でEhloキーワードと組み合わされます。
The max-future-release-interval is a positive integer indicating the maximum amount of time for which the message submission server (MSA) will hold messages for future release.
max-future-release-intervalは、メッセージ送信サーバー（MSA）が将来のリリースのメッセージを保持する最大時間を示す正の整数です。
Using ABNF [n2], the syntax of this parameter is as follows:
ABNF [N2]を使用して、このパラメーターの構文は次のとおりです。
future-release-integer = %x31-39 *8DIGIT
; integer in the range 1-999999999
; measured in seconds
max-future-release-interval = future-release-integer
The max-future-release-date-time is a timestamp, normalized to Universal Coordinated Time (UTC), indicating the most remote date and time in the future until which the MSA will hold messages for future release.
Max-Future-Release-Date-Timeはタイムスタンプであり、Universal Coordinated Time（UTC）に正規化されており、MSAが将来のリリースのメッセージを保持するまで、将来最もリモートの日付と時刻を示しています。
Using ABNF [n2], the syntax of this parameter is as follows:
ABNF [N2]を使用して、このパラメーターの構文は次のとおりです。
max-future-release-date-time = date-time
where the format of date-time is defined in [n10].
ここで、日付時間の形式は[n10]で定義されています。
3) When forming the portion of the EHLO reply containing the FUTURERELEASE keyword, the keyword is followed by the max-future-release-interval, and then the max-future-release-date-time. The keyword and two values are delimited by spaces.
3) ehloの返信の一部をFuturerEleaseキーワードを含む部分を形成する場合、キーワードの後にMax-Future-release-intervalが続き、次にMax-Future-release-date-Date-Timeが続きます。キーワードと2つの値は、スペースによって区切られています。
For example, the ABNF for a continuation line in the EHLO response that contains the FUTURERELEASE keyword is:
たとえば、futurerEleaseキーワードを含むEHLO応答の継続ラインのABNFは次のとおりです。
line = "250-FUTURERELEASE" SP max-future-release-interval SP max-future-release-date-time
line = "250-futurerelease" sp max-future-release-interval sp max-future-release-date-time
4) One required parameter, the hold-param, is added to the MAIL command using either the keyword "HOLDFOR" or the keyword "HOLDUNTIL".
4) 必要なパラメーター、Hold-Paramは、キーワード「Holdfor」またはキーワード「Holduntil」のいずれかを使用して、メールコマンドに追加されます。
The HOLDFOR parameter value is a future-release-interval, which is a positive integer indicating the amount of time the message is to be held by the MSA before release.
Holdforパラメーター値は将来のリリースインターバルであり、これはリリース前にメッセージがMSAによって保持される時間を示す正の整数です。
The HOLDUNTIL parameter value is a future-release-date-time, which is a timestamp, normalized to UTC, indicating the future date and time until which the message is to be held by the MSA before release.
Holduntilパラメーター値は、将来のリリース日であり、タイムスタンプであり、UTCに正規化されており、リリース前にメッセージがMSAによって保持されるまでの将来の日付と時刻を示します。
Using ABNF [n2], the syntax of this parameter is as follows:
ABNF [N2]を使用して、このパラメーターの構文は次のとおりです。
future-release-interval = future-release-integer
future-release-date-time = Internet-style-date-time-UTC
hold-for-param = "HOLDFOR=" future-release-interval
hold-foram = "holdfor =" future-release-interval
hold-until-param = "HOLDUNTIL=" future-release-date-time
hold-until-param = "holduntil =" future-release-date-time
hold-param = hold-for-param / hold-until-param
The absence of this parameter on the MAIL command does not imply a default value for this parameter.
メールコマンドにこのパラメーターがないことは、このパラメーターのデフォルト値を意味するものではありません。
5) The maximum length of a MAIL command is increased by 34 characters by the possible addition of the hold-param.
5) メールコマンドの最大長は、ホールドパラムを追加することにより、34文字増加します。
6) No additional SMTP verbs are defined by this extension.
6) この拡張機能によって追加のSMTP動詞は定義されていません。
7) This service extension is appropriate only for the SMTP submission protocol [n3]. This service extension is not appropriate for standard SMTP [n4].
7) このサービス拡張は、SMTP提出プロトコル[N3]にのみ適しています。このサービス拡張は、標準のSMTP [N4]には適していません。
It is unfortunate to define two seemingly identical ways to indicate a future message release time. When the client has both accurate time and accurate time zone information, either interval or date-time can be trivially calculated from the other. However, in the current world of clients, there are clients with accurate local time but no indication of their time zone, and clients without a suitably accurate clock. Based on the limited facilities available to these time-challenged clients, it is likely that only one or the other of these mechanisms will be useful.
将来のメッセージリリース時間を示すために、一見同一の2つの方法を定義するのは残念です。クライアントが正確な時間と正確なタイムゾーン情報の両方を持っている場合、間隔または日付時間のいずれかを他のものから簡単に計算できます。ただし、クライアントの現在の世界には、現地時間が正確なクライアントがありますが、タイムゾーンの兆候はなく、クライアントが適切に正確なクロックを持たないクライアントがいます。これらの時間削減されたクライアントが利用できる限られた施設に基づいて、これらのメカニズムのいずれかが役立つ可能性があります。
It is believed that servers will have accurate time, and can trivially convert between these mechanisms. It is also accepted that the protocol and implementation overhead of offering these two mechanisms is low, and that few interoperability challenges are anticipated.
サーバーには正確な時間があり、これらのメカニズム間で簡単に変換できると考えられています。また、これらの2つのメカニズムを提供するプロトコルと実装間のオーバーヘッドが低く、相互運用性の課題はほとんど予想されていないことも認められています。
1) An SMTP client preparing to use Future Message Release MUST first verify that the MSA supports this extension.
1) 将来のメッセージリリースを使用する準備をしているSMTPクライアントは、最初にMSAがこの拡張機能をサポートしていることを確認する必要があります。
2) An SMTP client using Future Message Release MUST include one, and only one, hold-param with the MAIL command.
2) 将来のメッセージリリースを使用してSMTPクライアントには、メールコマンドを使用して1つだけのHold-Paramを含める必要があります。
3) An SMTP client using Future Message Release with the "for" option of the hold-param MUST ensure that the future-release-interval is less than or equal to the max-future-release-interval advertised by the MSA.
3) Hold-Paramの「for」オプションを使用して将来のメッセージリリースを使用するSMTPクライアントは、将来のリリースインターバルがMSAによって宣伝されているMax-Future-release-intervalよりも等しくないことを確認する必要があります。
4) An SMTP client using Future Message Release with the "until" option of the hold-param MUST ensure that the future-release-date-time is earlier than or equal to the max-future-release-date-time advertised by the MSA.
4) hold-paramの「ut ut」オプションを使用して将来のメッセージリリースを使用するSMTPクライアントは、将来のリリース日間がMSAが宣伝するMax-Future-release-Date-Date-Timeよりも早くより早いか等しいことを確認する必要があります。
1) An MSA supporting Future Message Release MUST comply with the SMTP submission protocol as described in [n3].
1) [N3]で説明されているように、将来のメッセージリリースをサポートするMSAはSMTP提出プロトコルに準拠する必要があります。
2) An MSA supporting Future Message Release MUST NOT advertise this support (i.e. include the FUTURERELEASE keyword in its EHLO reply) on any port other than the submission port.
2) 将来のメッセージリリースをサポートするMSAは、提出ポート以外のポートにこのサポートを宣伝してはなりません（つまり、Ehloの返信にFuturerEleaseキーワードを含める）。
3) An MSA supporting Future Message Release MUST include the FUTURERELEASE keyword, and associated max-future-release-interval and max-future-release-date-time parameters, in its reply to the EHLO command.
3) 将来のメッセージリリースをサポートするMSAには、Ehloコマンドへの返信に、FuturerEleaseキーワード、および関連するMax-Future-release-intervalおよびmax-future-release-date-timeパラメーターを含める必要があります。
4) An MSA supporting Future Message Release MUST accept a MAIL command containing a valid hold-param, given that the MAIL command contains no other errors.
4) 将来のメッセージリリースをサポートするMSAは、メールコマンドに他のエラーが含まれていないことを考えると、有効なホールドパラムを含むメールコマンドを受け入れる必要があります。
5) An MSA that accepts a message with a request for Future Message Release indicating the "for" option MUST NOT release the message until the amount of time specified in the future-release-interval elapses.
5) 「for」オプションを示す将来のメッセージリリースのリクエストを含むメッセージを受け入れるMSAは、将来のリリースインターバルのエルプスで指定された時間までメッセージをリリースしてはなりません。
6) An MSA that accepts a message with a request for Future Message Release indicating the "until" option MUST NOT release the message until the date and time indicated by the future-release-date-time occurs.
6) 将来のメッセージリリースのリクエストを含むメッセージを受け入れるMSAは、将来のリリースデートタイムが示す日付と時刻が発生するまで、「まで」オプションがメッセージをリリースしてはならないことを示しています。
7) An MSA supporting Future Message Release MUST reject a MAIL command containing the "for" option specifying a value that is greater than the advertised max-future-release-interval, or otherwise invalid.
7) 将来のメッセージリリースをサポートするMSAは、「for」オプションを含むメールコマンドを拒否する必要があります。
8) An MSA supporting Future Message Release MUST reject a MAIL command containing the "until" option specifying a value that is later than the advertised max-future-release-date-time, or otherwise invalid.
8) 将来のメッセージリリースをサポートするMSAは、広告されたMax-Future-Release-Date-Timeよりも遅い値、またはその他の無効な値を指定する「ut ut」オプションを含むメールコマンドを拒否する必要があります。
9) An MSA supporting Future Message Release MUST reject a MAIL command containing more than one hold-param.
9) 将来のメッセージリリースをサポートするMSAは、複数のホールドパラムを含むメールコマンドを拒否する必要があります。
10) An MSA supporting Future Message Release, when rejecting a MAIL command per items 7, 8, or 9, above, SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply.
10）上記の項目7、8、または9の項目ごとのメールコマンドを拒否する場合、将来のメッセージリリースをサポートするMSAは、返信に返信コード501（パラメーターまたは引数の構文エラー[n4]）を返信に提供する必要があります。
11) An MSA supporting Future Message Release, when rejecting a MAIL command per items 7, 8, or 9, above, SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid command arguments [i1]) in the reply.
11）上記の項目7、8、または9の項目ごとのメールコマンドを拒否する場合、将来のメッセージリリースをサポートするMSAは、拡張されたメールシステムステータスコード5.5.4（無効なコマンド引数[i1]）を返信に提供する必要があります。
The Delivery Status Notification (DSN) service extension is described in [n7], and DSN message format is described in [n8].
配信ステータス通知（DSN）サービス拡張機能は[N7]で説明されており、DSNメッセージ形式は[N8]で説明されています。
1) An SMTP client MUST NOT request Future Message Release when sending a DSN to the MSA.
1) SMTPクライアントは、MSAにDSNを送信するときに将来のメッセージリリースを要求してはなりません。
1) If an MSA generates a DSN for a message that includes a Future Message Release request, the MSA MUST include an Arrival-Date field in the machine-readable body part of the DSN.
1) MSAが将来のメッセージリリースリクエストを含むメッセージのDSNを生成する場合、MSAには、DSNの機械読み取り可能なボディ部分に到着日フィールドを含める必要があります。
2) If an MSA generates a DSN for a message that includes a Future Message Release request, the MSA MUST include a Future-Release-Request field in the machine-readable body part of the DSN. The value of this field is the value of the HOLD parameter contained in the MAIL command of the original message.
2) MSAが将来のメッセージリリースリクエストを含むメッセージのDSNを生成する場合、MSAはDSNの機械可読ボディ部分に将来のリリースリクエストフィールドを含める必要があります。このフィールドの値は、元のメッセージのメールコマンドに含まれるホールドパラメーターの値です。
The Future-Release-Request field is an extension to the set of DSN per-message fields described in [n8]. Using ABNF [n2], the syntax of this new field is as follows:
Future-Release-Requestフィールドは、[N8]で説明されているDSNごとのフィールドのセットの拡張です。ABNF [N2]を使用して、この新しいフィールドの構文は次のとおりです。
orig-hold-param-value = ("for;" future-release-interval) /
("until;" future-release-date-time)
; this is the value of the HOLD param from
; the MAIL command of the original message
future-release-request-field = "Future-Release-Request:" orig-hold-param-value
future-release-request-field = "future-release-request：" orig-hold-param-value
If an MSA supports the Future Message release and Deliver By service extensions, it is possible for an SMTP client to make simultaneous requests for future message release and deliver-by times when submitting a message. A problem will occur if the future message release time is farther in the future than the deliver-by time. In order to honor the deliver-by request, the future message release request has to be ignored. In order to honor the future message release request, the deliver-by request has to be ignored. This section addresses that problem. The Deliver By extension is described in [n6].
MSAが将来のメッセージリリースをサポートし、サービス拡張機能ごとに配信する場合、SMTPクライアントは、メッセージを送信する際に将来のメッセージリリースと配信の同時リクエストを行うことができます。将来のメッセージのリリース時間が将来、配信よりも遠い場合に問題が発生します。配信リクエストを称えるために、将来のメッセージリリースリクエストを無視する必要があります。将来のメッセージリリースリクエストを称えるために、配信リクエストを無視する必要があります。このセクションでは、その問題について説明します。拡張による配信は[N6]で説明されています。
1) When an SMTP client wishes to use the Future Message Release and Deliver By extensions with the same message, the client MUST ensure that the specified deliver-by time is farther in the future than the specified ("until" option) or implied ("for" option) future message release time.
1) SMTPクライアントが将来のメッセージのリリースを使用し、同じメッセージを使用して拡張機能で配信したい場合、クライアントは指定された配信時間が指定された（ "まで"オプションまで）または暗示（ "「オプション）将来のメッセージリリース時間。
1) If an MSA supports Future Message Release and Deliver By extensions, and receives a message requesting the use of both extensions, the MSA MUST reject the MAIL command if it determines that the future message release time is farther in the future than the deliver-by time.
1) MSAが将来のメッセージのリリースをサポートし、拡張機能で配信し、両方の拡張機能の使用を要求するメッセージを受信した場合、MSAは将来のメッセージリリース時間が将来の配信よりも遠いと判断した場合、メールコマンドを拒否する必要があります。。
2) When an MSA is rejecting a MAIL command per item 1, above, it SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply.
2) 上記の項目1ごとにMSAがメールコマンドを拒否している場合、返信に返信コード501（パラメーターまたは引数[n4]の構文エラー[n4]）を返信する必要があります。
3) When an MSA is rejecting a MAIL command per item 1, above, it SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid command arguments [i1]) in the reply.
3) 上記の項目1ごとにMSAがメールコマンドを拒否している場合、返信に拡張されたメールシステムステータスコード5.5.4（無効なコマンド引数[i1]）を提供する必要があります。
The Message Disposition Notification (MDN) function is described in [n9].
メッセージ処分通知（MDN）関数は[N9]で説明されています。
1) An SMTP client MUST NOT request Future Message Release when sending an MDN to the MSA.
1) SMTPクライアントは、MDNをMSAに送信するときに将来のメッセージリリースを要求してはなりません。
The Future Message Release service extension presents a number of security considerations:
将来のメッセージリリースサービス拡張機能は、多くのセキュリティ上の考慮事項を提示します。
1) Unauthorized future-release messages provide a means to overwhelm the storage of an MSA. The authorization mechanisms required for the base mail submission protocol [n3] are expected to provide appropriate defense against such attacks.
1) 不正な将来のリリースメッセージは、MSAのストレージを圧倒する手段を提供します。基本メールの提出プロトコル[N3]に必要な承認メカニズムは、そのような攻撃に対する適切な防御を提供することが期待されています。
2) Authorized future message release without a per-user quota may also provide a way to overwhelm an MSA's storage. An MSA's future release message storage SHOULD be subject to a per-user quota.
2) ユーザーごとのクォータを使用せずに承認された将来のメッセージリリースは、MSAのストレージを圧倒する方法を提供する場合があります。MSAの将来のリリースメッセージストレージには、ユーザーごとのクォータの対象となります。
3) If an MSA is imposing a per-user quota on future-release message storage, and detects that an incoming future-release message will exceed the user's future-release message storage quota, the MSA MUST reject the MAIL command.
3) MSAが将来のリリースメッセージストレージにユーザーごとのクォータを押し付けており、将来の将来のリリースメッセージがユーザーの将来のリリースメッセージストレージクォータを超えることを検出する場合、MSAはメールコマンドを拒否する必要があります。
4) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply the reply code 552 (requested mail action aborted: exceeded storage allocation [n4]) in the reply.
4) MSAが5.3あたりのメールコマンドを拒否している場合、返信で返信コード552（要求されたメールアクション：超過ストレージ割り当て[N4]）を返信に提供する必要があります。
5) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply the new Enhanced Mail System Status Code defined for this purpose. This new status code updates [i1].
5) MSAが5.3あたりのメールコマンドを拒否している場合、この目的のために定義された新しい拡張されたメールシステムステータスコードを提供する必要があります。この新しいステータスコードが更新されます[I1]。
X.7.16 Future release per-user message quota exceeded
X.7.16 将来のリリースユーザーごとのメッセージクォータは超えました
There is insufficient per-user quota to queue the message for future release. This code suggests the client can submit again only after the per-user queue has drained.
将来のリリースのためにメッセージをキューするには、ユーザーごとのクォータが不十分です。このコードは、ユーザーごとのキューが排出された後にのみクライアントが再び送信できることを示唆しています。
X.7.17 Future release system message quota exceeded
X.7.17 将来のリリースシステムメッセージクォータが超えました
There is insufficient system quota to queue the message for future release. This code suggests the client can submit again after the system queue has drained.
将来のリリースのためにメッセージをキューするには、システムクォータが不十分です。このコードは、システムキューが排出された後にクライアントが再び送信できることを示唆しています。
6) Inaccurate time on the MSA may result in premature or delayed release of messages. Both HOLDUNTIL and HOLDFOR request mechanisms are sensitive to inaccurate or changing clocks on the MSA.
6) MSAの不正確な時間は、メッセージの早期または遅延のリリースをもたらす可能性があります。HolduntilとHoldfor Requestメカニズムは、MSAのクロックの変更または変更に敏感です。
7) Some element of deception is inherent in the future message release concept. The message release time is intentionally delayed past the time it would otherwise be released; hence, the message delivery time is delayed past the time it would otherwise be delivered. This extension provides no mechanism for hiding this from the message recipient. The RFC 2822 [n5] message header, and specifically the Date field, remain unchanged after submission. While a sending client MAY elect to place the future-message-release-time as the date in the Date field, there is no requirement or expectation that the Received fields and other trace information be modified by the transport system to further this deception.
7) 欺ceptionの要素は、将来のメッセージリリースの概念に固有のものです。メッセージのリリース時間は、それ以外の場合はリリースされる時間を過ぎて意図的に遅れます。したがって、メッセージの配信時間は、それ以外の場合は配信される時間を経て遅れます。この拡張機能は、メッセージ受信者からこれを隠すメカニズムを提供しません。RFC 2822 [N5]メッセージヘッダー、特に日付フィールドは、提出後も変更されていません。送信クライアントは、日付フィールドの日付として将来の解放時間を配置することを選択できますが、受信したフィールドやその他のトレース情報を輸送システムによって変更して、この欺ceptionを促進する要件や期待はありません。
This extension has been added to the list of SMTP Service Extensions on the Mail Parameters Web page.
この拡張子は、Mail Parameters WebページのSMTPサービス拡張機能のリストに追加されています。
Much of the credit for this document is due to the LEMONADE working group. Through many revisions, the discussion resulted in fundamental new understandings of this protocol and corresponding refinement of the implied requirements and protocol. Special thanks to those who patiently lead the WG to understand that doing both interval and date-time was the pragmatically correct approach to the needs of diverse clients.
この文書のクレジットの多くは、レモネードワーキンググループによるものです。多くの改訂を通じて、この議論はこのプロトコルの根本的な新しい理解と、暗黙の要件とプロトコルの対応する改良をもたらしました。WGを辛抱強くリードして、間隔と日付の両方の時間を実行することが、多様なクライアントのニーズに対する実用的に正しいアプローチであることを理解してくれた人々に感謝します。
[n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[n1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[n2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[n2] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[n3] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[n3] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[n4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[n4] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[n5] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[n5] Resnick、P。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[n6] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[n6] Newman、D。、「SMTP Service Extensionによる配信」、RFC 2852、2000年6月。
[n7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[n7] ムーア、K。、「配信ステータス通知（DSNS）のSimple Mail Transfer Protocol（SMTP）サービス拡張」、RFC 3461、2003年1月。
[n8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[n8] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[n9] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[n9] Hansen、T。およびG. Vaudreuil、「メッセージ処分通知」、RFC 3798、2004年5月。
[n10] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002
[n10] Klyne、G。and C. Newman、「インターネット上の日時：タイムスタンプ」、RFC 3339、2002年7月
[i1] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[i1] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。
Authors' Addresses
著者のアドレス
Gregory A. White 6519 Camille Ave. Dallas, TX 75252 USA EMail: g.a.white@tx.rr.com
グレゴリーA.ホワイト6519カミーユアベニュー、ダラス、テキサス75252 USAメール：g.a.white@tx.rr.com
Gregory M. Vaudreuil Alcatel-Lucent 9489 Bartgis Ct Frederick, MD 21702 USA EMail: GregV@ieee.org
GREGORY M. VAUDREUIL ALCATEL-LUCENT 9489 BARTGIS CT FREDERICK、MD 21702 USAメール：gregv@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。