RFC4865 日本語訳
4865 SMTP Submission Service Extension for Future Message Release. G.White, G. Vaudreuil. May 2007. (Format: TXT=21495 bytes) (Updates RFC3463, RFC3464) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. White
Request for Comments: 4865 Independent
Updates: 3463, 3464 G. Vaudreuil
Category: Standards Track Alcatel-Lucent
May 2007
コメントを求めるワーキンググループのG.の白い要求をネットワークでつないでください: 4865の独立しているアップデート: 3463、3464G.ボードルイカテゴリ: 2007年5月にアルカテル透明な標準化過程
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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服従プロトコルと拡大を定義します。 この拡大は、クライアントが将来待ち行列で定刻まで保持されるべきであるメッセージにサーバベースのストレージを使用することを許可します。 これはクライアントの役に立ちます(地方のストレージを持っていないか、またはそうでなければ、定刻で配送へのメッセージを発表できません)。
1. Introduction
1. 序論
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.
将来配送へのメッセージを構成して、送るために、声のメッセージング共同体の中に広く使用された特徴があります。 これはおよそ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]を使用します。
White & Vaudreuil Standards Track [Page 1] RFC 4865 SMTP Future Message Release May 2007
白とボードルイ規格はメッセージリリース2007年5月に4865年のRFC SMTP未来を追跡します[1ページ]。
2. Terminology
2. 用語
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[n1]で説明されるように本書では解釈されることであるべきですか?
3. Framework
3. フレームワーク
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服従のためのFuture Message Releaseサービス拡張子は、SMTP服従プロトコル[n3]を広げるのに、SMTPサービス拡張機能[n4]を使用します。 以下の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) このサービス拡大に関連しているExtended 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つの必要なパラメタで、将来のリリース間隔に最大限にして、将来のリリース日付の時間に最大限にするのは[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.
将来のリリース間隔に最大限にするのは、メッセージ服従サーバ(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
将来のリリース整数=%x31-39*8DIGIT。 範囲1-999999999の整数。 秒に測定されます。
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.
将来のリリース日付の時間に最大限にするのは、MSAが今後のリリースへのメッセージを保持する将来最もリモートな日時を示すUniversal Coordinated Time(UTC)に正常にされたタイムスタンプです。
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]で定義されるところ。
White & Vaudreuil Standards Track [Page 2] RFC 4865 SMTP Future Message Release May 2007
白とボードルイ規格はメッセージリリース2007年5月に4865年のRFC SMTP未来を追跡します[2ページ]。
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) FUTURERELEASEキーワードを含むEHLO回答の部分を形成すると、キーワードは、リリース間隔が最大未来までに続かれていて将来のリリース日付の時間に最大限にします。 キーワードと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
将来のリリース日付の時間に最大限にした状態で="250-FUTURERELEASE"SP最大未来のリリース間隔SPを裏打ちしてください。
4) One required parameter, the hold-param, is added to the MAIL
command using either the keyword "HOLDFOR" or the keyword
"HOLDUNTIL".
4) 1つの必要なパラメタ、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パラメタ価値はリリース日付の時間未来です。(その未来はリリースの前にMSAによって開催されるメッセージがことである将来の日時を示すUTCに正常にされたタイムスタンプです)。
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
リリース日付の時間未来=インターネットスタイル時間UTC日付
hold-for-param = "HOLDFOR=" future-release-interval
paramのための保持は「HOLDFOR=」将来のリリース間隔と等しいです。
hold-until-param = "HOLDUNTIL=" future-release-date-time
paramまでの保持は「HOLDUNTIL=」将来のリリース日付の時間と等しいです。
hold-param = hold-for-param / hold-until-param
保持-paramはparamまでの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) メールコマンドの最大の長さは保持-paramの可能な追加によって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]には、このサービス拡大は適切ではありません。
White & Vaudreuil Standards Track [Page 3] RFC 4865 SMTP Future Message Release May 2007
白とボードルイ規格はメッセージリリース2007年5月に4865年のRFC SMTP未来を追跡します[3ページ]。
4. Behavior
4. 振舞い
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つの外観上同じ方法を定義するのは不運です。 クライアントに正確な時間と正確な時間帯の情報の両方があると、もう片方から間隔か日付-時間のどちらかについて些細なことに計算できます。 しかしながら、クライアントの現在の世界に、彼らの時間帯の現地時間にもかかわらず、いいえの正確なしるしを伴うクライアント、および適当に正確な時計のないクライアントがいます。 これらの時間で挑戦されたクライアントにとって、利用可能な限られた施設に基づいて、これらのメカニズムの1かもう片方だけが役に立つのは、ありそうです。
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つのメカニズムを提供するプロトコルと実装オーバーヘッドが低く、わずかな相互運用性挑戦しか予期されないと受け入れます。
4.1. SMTP Client
4.1. SMTPクライアント
1) An SMTP client preparing to use Future Message Release MUST first
verify that the MSA supports this extension.
1) Future Message Releaseを使用するのを準備しているSMTPクライアントは、最初に、MSAがこの拡大をサポートすることを確かめなければなりません。
2) An SMTP client using Future Message Release MUST include one, and
only one, hold-param with the MAIL command.
2) Future Message Releaseを使用しているSMTPクライアントは1、および1だけ、メールコマンドがある保持-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) 保持-paramの“for"オプションがあるFuture Message Releaseを使用しているSMTPクライアントは、将来のリリース間隔がそれほど将来のリリース間隔に最大限にしないことをMSAによって広告を出された保証しなければなりません。
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) 保持-paramの“until"オプションがあるFuture Message Releaseを使用しているSMTPクライアントは今後のリリース日付-時間が確実にMSAによって広告に掲載された最大今後のリリース日付-時間と、より初期であるか等しくなるようにしなければなりません。
4.2. MSA
4.2. MSA
1) An MSA supporting Future Message Release MUST comply with the SMTP
submission protocol as described in [n3].
1) Future Message ReleaseをサポートするMSAは[n3]で説明されるように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) Future Message ReleaseをサポートするMSAは服従ポート以外のどんなポートの上にもこのサポート(すなわち、EHLO回答にFUTURERELEASEキーワードを含んでいる)の広告を出してはいけません。
White & Vaudreuil Standards Track [Page 4] RFC 4865 SMTP Future Message Release May 2007
白とボードルイ規格はメッセージリリース2007年5月に4865年のRFC SMTP未来を追跡します[4ページ]。
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) Future Message ReleaseをサポートするMSAはFUTURERELEASEキーワードの、そして、関連している将来のリリース間隔に最大限にしていて将来のリリース日付の時間に最大限にしているパラメタを含まなければなりません、EHLOコマンドに関する回答で。
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) Future Message ReleaseをサポートするMSAは有効な保持-paramを含むメールコマンドを受け入れなければなりません、メールコマンドが他の誤りを全く含んでいないなら。
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) Future Message Releaseを求める要求が、時間が指定するまで“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) リリース日付の時間未来までに示された日時が起こるまで、Future Message Releaseを求める要求が“until"オプションを示しているメッセージを受け入れる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) Future Message Releaseをサポートする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) Future Message ReleaseをサポートするMSAは広告を出すより将来のリリース日付の時間に最大限にするか、またはそうでなければ、無効の状態で遅れる値を指定する“until"オプションを含むメールコマンドを拒絶しなければなりません。
9) An MSA supporting Future Message Release MUST reject a MAIL
command containing more than one hold-param.
9) Future Message ReleaseをサポートするMSAは1保持-paramを含むメールコマンドを拒絶しなければなりません。
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あたり1つのメールコマンドを拒絶するとき、MSAがFuture Message Releaseをサポートして、上に、SHOULDは回答における回答コード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あたり1つのメールコマンドを拒絶するとき、MSAがFuture Message Releaseをサポートして、上に、SHOULDは回答でEnhancedメールSystem Status Code5.5.4(無効のコマンド主張[i1])を供給します。
White & Vaudreuil Standards Track [Page 5] RFC 4865 SMTP Future Message Release May 2007
白とボードルイ規格はメッセージリリース2007年5月に4865年のRFC SMTP未来を追跡します[5ページ]。
5. Protocol Interactions
5. プロトコル相互作用
5.1. Interaction with the DSN SMTP Service Extensions
5.1. DSN SMTPサービス拡張子との相互作用
The Delivery Status Notification (DSN) service extension is described in [n7], and DSN message format is described in [n8].
Delivery Status Notification(DSN)サービス拡張子は[n7]で説明されます、そして、DSNメッセージ・フォーマットは[n8]で説明されます。
5.1.1. SMTP Client Interaction with DSN
5.1.1. DSNがあるSMTPクライアントとの対話
1) An SMTP client MUST NOT request Future Message Release when
sending a DSN to the MSA.
1) DSNをMSAに送るとき、SMTPクライアントはFuture Message Releaseを要求してはいけません。
5.1.2. MSA Interaction with DSN
5.1.2. DSNとのMSA相互作用
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がFuture Message Release要求を含んでいるメッセージのためにDSNを生成するなら、MSA MUSTはDSNの機械可読な身体の部分にArrival-年月日欄を含んでいます。
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がFuture Message Release要求を含んでいるメッセージのためにDSNを生成するなら、MSA MUSTはDSNの機械可読な身体の部分のFuture要求を発表している分野を含んでいます。 この分野の値はオリジナルのメッセージのメールコマンドに含まれたHOLDパラメタの値です。
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リリース要求分野は[n8]で説明された1メッセージあたりの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
orig保持param価値が等しい、(「」、;、将来のリリース間隔) /、(「」、;、将来のリリース日付の時間)、。 これがHOLD paramの値である、。 オリジナルのメッセージのメールコマンド
future-release-request-field = "Future-Release-Request:"
orig-hold-param-value
今後のリリースは分野を要求します。= 「未来は要求を発表します」。 orig保持param価値
5.2. Interaction with the DELIVERBY SMTP Service Extension
5.2. DELIVERBY SMTPサービス拡張子との相互作用
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が、Future MessageリリースとDeliver Byサービスが拡大であるとサポートするなら、SMTPクライアントが今後のメッセージリリースと近く配送するのを求める同時の要求を回にするのは、可能です。 メッセージリリース時間未来が将来近く配送する時間より遠いなら、問題は起こるでしょう。 近く配送する要求を光栄に思うために、今後のメッセージリリース要求は無視されなければなりません。 今後のメッセージリリース要求を光栄に思うために、近く配送する要求は無視されなければなりません。 このセクションはそのその問題を訴えます。 Deliver By拡張子は[n6]で説明されます。
White & Vaudreuil Standards Track [Page 6] RFC 4865 SMTP Future Message Release May 2007
白とボードルイ規格はメッセージリリース2007年5月に4865年のRFC SMTP未来を追跡します[6ページ]。
5.2.1. SMTP Client Interaction with DELIVERBY
5.2.1. DELIVERBYがあるSMTPクライアントとの対話
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クライアントが同じメッセージがあるFuture Message ReleaseとDeliver By拡張子を使用したがっているとき、クライアントは指定された近く配送する時間が確実に将来メッセージリリース時間の指定(“until"オプション)にされるのであるか暗示している(“for"オプション)未来より遠くなるようにしなければなりません。
5.2.2. MSA Interaction with DELIVERBY
5.2.2. DELIVERBYとのMSA相互作用
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がFuture Message ReleaseとDeliver Byが拡大であるとサポートして、両方の拡張子の使用を要求するメッセージを受け取るなら、メッセージリリース時間未来が将来近く配送する時間より遠いことを決定するなら、MSA MUSTはメールコマンドを拒絶します。
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) MSAが上で項目1あたり1つのメールコマンドにそれを拒絶しているとき、SHOULDは回答における回答コード501(パラメタか主張[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) MSAが上で項目1あたり1つのメールコマンドにそれを拒絶しているとき、SHOULDは回答でEnhancedメールSystem Status Code5.5.4(無効のコマンド主張[i1])を供給します。
5.3. Interaction with the MDN Function
5.3. MDN機能との相互作用
The Message Disposition Notification (MDN) function is described in [n9].
Message Disposition Notification(MDN)機能は[n9]で説明されます。
5.3.1. SMTP Client Interaction with MDN
5.3.1. MDNがあるSMTPクライアントとの対話
1) An SMTP client MUST NOT request Future Message Release when
sending an MDN to the MSA.
1) MDNをMSAに送るとき、SMTPクライアントはFuture Message Releaseを要求してはいけません。
6. Security Considerations
6. セキュリティ問題
The Future Message Release service extension presents a number of security considerations:
Future Message Releaseサービス拡張子は多くのセキュリティ問題を提示します:
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) また、1ユーザあたり1つの割当てのない認可された今後のメッセージリリースはMSAのストレージを圧倒する方法を提供するかもしれません。 MSAの未来はユーザへの対象が割当てであったならメッセージストレージSHOULDをリリースします。
White & Vaudreuil Standards Track [Page 7] RFC 4865 SMTP Future Message Release May 2007
白とボードルイ規格はメッセージリリース2007年5月に4865年のRFC SMTP未来を追跡します[7ページ]。
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は1ユーザあたり1つの割当てを未来リリースメッセージストレージに課していて、それを検出します。入って来る未来リリースメッセージはユーザの今後のリリースメッセージストレージ割当てを超えて、MSA MUSTはメールコマンドを拒絶します。
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あたり1つのメールコマンドを拒絶していて、それは回答がコード化するSHOULD供給です。いつ、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あたり1つのメールコマンドを拒絶していて、それは新しいEnhancedメールSystem Status Codeがこのために定義したSHOULD供給であるか。 この新しいステータスコードは[i1]をアップデートします。
X.7.16 Future release per-user message quota exceeded
1ユーザあたりのメッセージ割当てが超えていた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.
今後のリリースへのメッセージを列に並ばせるために、1ユーザあたりの不十分な割当てがあります。 このコードは、1ユーザあたりの待ち行列が排水した後にだけクライアントが再び提出できるのを示します。
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の両方が、メカニズムが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) 詐欺の何らかの要素は将来のメッセージリリース概念が固有です。 そうでなければ、それがリリースされるだろうというとき、メッセージリリース時間は故意に過ぎて遅れます。 したがって、そうでなければ、それが提供されるだろうというとき、メッセージ納期は過ぎて遅れます。 この拡大はメッセージ受取人からこれを隠すのにメカニズムを全く提供しません。 RFC2822[n5]メッセージヘッダー、および明確にDate分野は服従の後に変わりがありません。 送付クライアントが、入賞するのを選んでいるかもしれない間、Date分野の日付として、要件が全くないか、または期待にはそのReceived分野の、そして、他のトレース情報がある将来のメッセージリリース時間に輸送システムによって変更されて、この詐欺を促進してください。
White & Vaudreuil Standards Track [Page 8] RFC 4865 SMTP Future Message Release May 2007
白とボードルイ規格はメッセージリリース2007年5月に4865年のRFC SMTP未来を追跡します[8ページ]。
7. IANA Considerations
7. IANA問題
This extension has been added to the list of SMTP Service Extensions on the Mail Parameters Web page.
メールParametersウェブページのSMTP Service Extensionsのリストにこの拡大を追加してあります。
8. Acknowledgments
8. 承認
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.
このドキュメントのためのクレジットの多くがLEMONADEワーキンググループのためです。 多くの改正で、議論はこのプロトコルの基本的な新しい疎通と暗示している要件とプロトコルの対応する気品をもたらしました。 WGが、間隔と日付-時間の両方をするのが、さまざまのクライアントの必要性への実践的に正しいアプローチであったのを理解しているように我慢強く導く人への特別な感謝。
9. Normative References
9. 引用規格
[n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[n1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[n2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[n2] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[n3] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC
4409, April 2006.
[n3] GellensとR.とJ.Klensin、「メールのためのメッセージ提案」、RFC4409、2006年4月。
[n4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[n4] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[n5] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[n5] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[n6] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June
2000.
ニューマン、D.が「SMTPサービス拡張子で提供する」[n6]、RFC2852、2000年6月。
[n7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC 3461,
January 2003.
[n7]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
[n8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 3464, January 2003.
[n8] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
[n9] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[n9] ハンセン、T.、およびG.ボードルイ(「メッセージ気質通知」、RFC3798)は2004がそうするかもしれません。
[n10] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002
[n10]Klyne(G.とC.ニューマン)は「インターネットで以下の日付を入れて、調節します」。 「タイムスタンプ」、RFC3339、2002年7月
White & Vaudreuil Standards Track [Page 9] RFC 4865 SMTP Future Message Release May 2007
白とボードルイ規格はメッセージリリース2007年5月に4865年のRFC SMTP未来を追跡します[9ページ]。
10. Informative References
10. 有益な参照
[i1] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
January 2003.
[i1] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、2003年1月。
Authors' Addresses
作者のアドレス
Gregory A. White 6519 Camille Ave. Dallas, TX 75252 USA EMail: g.a.white@tx.rr.com
グレゴリー・A.ホワイト6519カミールAve。 テキサス75252ダラス(米国)はメールされます: g.a.white@tx.rr.com
Gregory M. Vaudreuil Alcatel-Lucent 9489 Bartgis Ct Frederick, MD 21702 USA EMail: GregV@ieee.org
グレゴリー・M.ボードルイ9489年のアルカテル透明なBartgis ctフレディリック、Md21702米国メール: GregV@ieee.org
White & Vaudreuil Standards Track [Page 10] RFC 4865 SMTP Future Message Release May 2007
白とボードルイ規格はメッセージリリース2007年5月に4865年のRFC SMTP未来を追跡します[10ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
White & Vaudreuil Standards Track [Page 11]
ホワイトとボードルイ標準化過程[11ページ]
一覧
スポンサーリンク
