RFC5248 日本語訳
5248 A Registry for SMTP Enhanced Mail System Status Codes. T. Hansen,J. Klensin. June 2008. (Format: TXT=23845 bytes) (Updates RFC3463, RFC4468, RFC4954) (Also BCP0138) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Hansen Request for Comments: 5248 AT&T Laboratories BCP: 138 J. Klensin Updates: 3463, 4468, 4954 June 2008 Category: Best Current Practice
コメントを求めるワーキンググループT.ハンセン要求をネットワークでつないでください: 5248AT&T研究所BCP: 138 J.Klensinアップデート: 4468、4954 3463、年2008年6月のカテゴリ: 最も良い現在の習慣
A Registry for SMTP Enhanced Mail System Status Codes
SMTPのための登録はメールシステムステータスコードを高めました。
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Abstract
要約
The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes. While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry.
高められたメールシステムステータスコードのための仕様(RFC3463)は、新法モデルを確立して、ステータスコードの収集を記載します。 より多くのコードが時間がたつにつれて加えられると予期していた間、それはそれらのコードを示して、追跡するのに明白なメカニズムを提供しませんでした。 このドキュメントは、高められた状態がコード化するメールシステムにIANA登録を指定して、コードが今までのところ発行された標準化過程文書に確立されている状態で、その登録を初期化します、産業で確立するようになった他のコードと同様に。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 2
2.1. SMTP Enhanced Status Codes Registry . . . . . . . . . . . . 2
2.2. Review Process for New Values . . . . . . . . . . . . . . . 4
2.3. Registration Updates . . . . . . . . . . . . . . . . . . . 4
2.4. Initial Values . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 2 2.1。 SMTPは.22.2にステータスコード登録を高めました。 新しい値. . . . . . . . . . . . . . . 4 2.3のためにプロセスを見直してください。 登録は.42.4をアップデートします。 値. . . . . . . . . . . . . . . . . . . . . . 5 3に頭文字をつけてください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 8 4。 承認. . . . . . . . . . . . . . . . . . . . . . . 9 5。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1。 引用規格. . . . . . . . . . . . . . . . . . . 9 5.2。 有益な参照. . . . . . . . . . . . . . . . . . 9
Hansen & Klensin Best Current Practice [Page 1] RFC 5248 SMTP Enhanced Status Code Registry June 2008
ステータスコード登録2008年6月に高められたハンセンとKlensinの最も良い現在の習慣[1ページ]RFC5248SMTP
1. Introduction
1. 序論
Enhanced Status Codes for SMTP were first defined in [RFC1893], which was subsequently replaced by [RFC3463]. While it anticipated that more codes would be added over time (see section 2 of [RFC3463]), it did not provide an explicit mechanism for registering and tracking those codes. Since then, various RFCs have been published and internet drafts proposed that define additional status codes. However, without an IANA registry, conflicts in definitions have begun to appear.
SMTPのための高められたStatus Codesは最初に、[RFC1893]で定義されました。(それは、次に、[RFC3463]に取り替えられました)。 より多くのコードが時間がたつにつれて加えられると予期していた間([RFC3463]のセクション2を見てください)、それはそれらのコードを示して、追跡するのに明白なメカニズムを提供しませんでした。 それ以来、様々なRFCsは追加ステータスコードを定義する提案された発行されるのとインターネット草稿です。 しかしながら、IANA登録がなければ、定義における闘争は現れ始めました。
This RFC defines such an IANA registry and was written to help prevent further conflicts from appearing in the future. It initializes the registry with the established standards-track enhanced status codes from [RFC3463], [RFC3886], [RFC4468], and [RFC4954]. In addition, this document adds several codes to the registry that were established by various internet drafts and have come into common use, despite the expiration of the documents themselves.
このRFCは、そのようなIANA登録を定義して、闘争が将来現れるのをさらに防ぐのを助けるために書かれました。 それは確立した標準化過程高められたステータスコードで[RFC3463]、[RFC3886]、[RFC4468]、および[RFC4954]から登録を初期化します。 さらに、このドキュメントは登録への様々なインターネット草稿で設立されて、一般の使用に入ったいくつかのコードを加えます、ドキュメント自体の満了にもかかわらず。
As specified in [RFC3463], an enhanced status code consists of a three-part code, with each part being numeric and separated by a period character. The three portions are known as the class sub- code, the subject sub-code, and the detail sub-code. In the tables, a wildcard for the class sub-code is represented by an X, a wildcard for a subject sub-code is represented by an XXX, and a wildcard for a detail sub-code is represented by a YYY. For example, 3.XXX.YYY has an unspecified subject sub-code and an unspecified status code, and X.5.0 is has an unspecified class sub-code. (This is a change from [RFC3463], which uses XXX for both the subject sub-code and detail sub-code wildcards.)
[RFC3463]で指定されるように、高められたステータスコードは3パートコードから成ります、各部分が数値であり、期間のキャラクタによって切り離されている状態で。 3つの部分がクラスサブコード、対象のサブコード、および詳細サブコードとして知られています。 テーブルでは、クラスサブコードのためのワイルドカードはXによって表されます、そして、対象のサブコードのためのワイルドカードはXXXによって表されます、そして、詳細サブコードのためのワイルドカードはYYYによって表されます。 例えば、3.XXX.YYYには不特定の対象のサブコードと不特定のステータスコードがあります、そして、X.5.0は持っています。サブコードであるのに不特定のクラスを持っています。 (これは[RFC3463]からの変化です。)(]は対象のサブコードと詳細サブコードワイルドカードの両方にXXXを使用します)。
2. IANA Considerations
2. IANA問題
2.1. SMTP Enhanced Status Codes Registry
2.1. SMTPはステータスコード登録を高めました。
IANA has created the registry "SMTP Enhanced Status Codes". The SMTP Enhanced Status Codes registry will have three tables:
IANAは登録を作成しました。「SMTPはステータスコードを高めました」。 SMTP Enhanced Status Codes登録には、3個のテーブルがあるでしょう:
o Class Sub-Codes
Each of the entries in this table represent class sub-codes and
all have an unspecified subject sub-code and an unspecified detail
sub-code.
o このテーブルのエントリーのクラスSub-コードEachはすべてサブコードであるのに不特定の対象を持っていて、クラスサブコードを表して、サブコードであるのに不特定の詳細を持っています。
o Subject Sub-Codes
Each of the entries in this table represent subject sub-codes and
all have an unspecified class sub-code and an unspecified detail
sub-code.
o このテーブルのエントリーの対象のSub-コードEachは対象のサブコードを表して、不特定のクラスサブコードと不特定の詳細をサブコードであるのにすべて持っています。
Hansen & Klensin Best Current Practice [Page 2] RFC 5248 SMTP Enhanced Status Code Registry June 2008
ステータスコード登録2008年6月に高められたハンセンとKlensinの最も良い現在の習慣[2ページ]RFC5248SMTP
o Enumerated Status Codes
Each of the entries in this table represent the combination of a
subject sub-code and a detail sub-code. All entries will have an
unspecified class sub-code, a specified subject sub-code, and a
specified detail sub-code.
o このテーブルのエントリーの列挙されたStatus Codes Eachは対象のサブコードと詳細サブコードの組み合わせを表します。 すべてのエントリーが不特定のクラスサブコード、指定主語サブコード、および指定された詳細をサブコードであるのに持つでしょう。
Each entry in the tables will include the following. (The sub-code tables will not have the Associated Basic Status Code entries.)
テーブルの各エントリーは以下を含むでしょう。 (サブコードテーブルには、Associated Basic Status Codeエントリーがないでしょう。)
Code: The status code. For example,
3.XXX.YYY is a class sub-code with an
unspecified subject sub-code and an
unspecified detail sub-code, and X.5.0
is an enumerated status code with an
unspecified class sub-code.
コード: ステータスコード。 例えば、3.XXX.YYYは不特定の不特定の対象がサブコードである、サブコードである詳細のサブコードのクラスです、そして、X.5.0は不特定のクラスがサブコードであることの列挙されたステータスコードです。
Summary: or Sample Text: For class and subject sub-codes, this
is the summary of the use for the sub-
code shown in section 2 of [RFC3463].
For enumerated status codes, this is an
example of a message that might be sent
along with the code.
概要: または、テキストを抽出してください: クラスと対象のサブコードのために、これは[RFC3463]のセクション2で示されたサブコードの使用の概要です。 列挙されたステータスコードのために、これはコードと共に送られるかもしれないメッセージに関する例です。
Associated Basic Status Code: For enumerated status codes, the basic
status code(s) of [RFC2821] with which
it is usually associated. This may
also have a value such as "Any" or "Not
given". NOTE: This is a non-exclusive
list. In particular, the entries that
list some basic status codes for an
Enhanced Status Code might allow for
other basic status codes, while the
entries denoted "Not given" can be
filled in by updating the IANA registry
through updates to this document or at
the direction of the IESG.
関連基本的なステータスコード: 列挙されたステータスコード、通常、それが関連している[RFC2821]の基本的なステータスコードのために。 また、「いずれ」などの値を持っているかもしれないか、または「与えられなかった」これ。 以下に注意してください。 これは非排他的なリストです。 特に、Enhanced Status Codeのためにいくつかの基本的なステータスコードを記載するエントリーは他の基本的なステータスコードを考慮するかもしれません、このドキュメントへのアップデートを通して、または、IESGの方向でIANA登録をアップデートすることによって、「与えられていなく」て、指示されたエントリーに記入できますが。
Description: A short description of the code.
記述: コードの短い記述。
Reference: A reference to the document in which
the code is defined. This reference
should note whether the relevant
specification is standards-track, best
current practice, or neither, using one
of "(Standards track)", "(Best current
practice)" or "(Not standards track)".
参照: コードが定義されるドキュメントの参照。 この参照は1つを使用して、関連仕様が「(標準化過程)」、「(最も良い電流習慣)」で標準化過程かそれとも、最も良い現在の習慣かそれとも、どちらもでないか、そして、「(規格道でない)」に注意するべきです。
Hansen & Klensin Best Current Practice [Page 3] RFC 5248 SMTP Enhanced Status Code Registry June 2008
ステータスコード登録2008年6月に高められたハンセンとKlensinの最も良い現在の習慣[3ページ]RFC5248SMTP
Submitter: The identity of the submitter, usually
the document author.
Submitter: submitter、通常ドキュメント作者のアイデンティティ。
Change Controller: The identity of the change controller
for the specification. This will be
"IESG" in the case of IETF-produced
documents.
コントローラを変えてください: 仕様のための変化コントローラのアイデンティティ。 これはIETFによって生産されたドキュメントの場合で"IESG"でしょう。
An example of an entry in the enumerated status code table would be:
列挙されたステータスコードテーブルのエントリーに関する例は以下の通りでしょう。
Code: X.0.0
Sample Text: Other undefined Status
Associated basic status code: Any
Description: Other undefined status is the only undefined
error code. It should be used for all errors for
which only the class of the error is known.
Reference: RFC 3463 (Standards track)
Submitter: G. Vaudreuil
Change controller: IESG.
コード: X.0.0はテキストを抽出します: 他の未定義のStatus Associated基本的なステータスコード: どんな記述も: 他の未定義の状態は唯一の未定義のエラーコードです。 それは誤りのクラスだけが知られているすべての誤りに使用されるべきです。 参照: RFC3463(標準化過程)Submitter: G。 ボードルイChangeコントローラ: IESG。
2.2. Review Process for New Values
2.2. 新しい値のための吟味の過程
Entries in this registry are expected to follow the "Specification Required" model ([RFC5226]) although, in practice, most entries are expected to derive from standards-track documents. Non-standards- track documents that specify codes to be registered should be readily available. The principal purpose of this registry is to avoid confusion and conflicts among different definitions or uses for the same code.
この登録のエントリーは、実際にはエントリーが予想される大部分が標準化過程文書に由来していますが、「仕様が必要である」というモデル([RFC5226])に従うと予想されます。 非、-登録されて、容易に利用可能であるべきであるということになるようにコードを指定するドキュメントを規格で追跡してください。 この登録の主要な目的は同じコードへの異なった定義か用途の中で混乱と闘争を避けることです。
2.3. Registration Updates
2.3. 登録アップデート
Standards-track registrations may be updated if the relevant standards are updated as a consequence of that action. Non- standards-track entries may be updated by the listed change controller. Only the entry's short description or references may be modified in this way, not the code or associated text. In exceptional cases, any aspect of any registered entity may be updated at the direction of the IESG (for example, to correct a conflict).
その動作の結果として関連規格をアップデートするなら、標準化過程登録証明書をアップデートするかもしれません。 非標準化過程エントリーは記載された変化コントローラによってアップデートされるかもしれません。 エントリーだけの短い記述か参照がコードか関連テキストではなく、このように変更されるかもしれません。 例外的な場合では、IESG(例えば闘争を修正する)の方向でどんな登録された実体のどんな局面もアップデートするかもしれません。
Hansen & Klensin Best Current Practice [Page 4] RFC 5248 SMTP Enhanced Status Code Registry June 2008
ステータスコード登録2008年6月に高められたハンセンとKlensinの最も良い現在の習慣[4ページ]RFC5248SMTP
2.4. Initial Values
2.4. 初期の値
The initial values for the class and subject sub-code tables are to be populated from section 2 of [RFC3463]. Specifically, these are the values for 2.XXX.YYY, 4.XXX.YYY, and 5.XXX.YYY for the Class Sub- Code table, and the values X.0.YYY, X.1.YYY, X.2.YYY, X.3.YYY, X.4.YYY, X.5.YYY, X.6.YYY, and X.7.YYY for the Subject Sub-Code table. The code, sample text, and description for each entry are to be taken from [RFC3463]. Each entry is to use [RFC3463] as the reference, submitted by G. Vaudreuil, and change controlled by the IESG. There are no associated detail sub-code values for the class and subject sub-code tables.
クラスと対象のサブコードテーブルのための初期の値は[RFC3463]のセクション2から居住されることです。 明確に、これらは、Subject Sub-コードテーブルのための値の2.XXX.YYYのための値と、4.XXX.YYYと、Class Subコードテーブルのための5.XXX.YYYと、X.0.YYYと、X.1.YYYと、X.2.YYYと、X.3.YYYと、X.4.YYYと、X.5.YYYと、X.6.YYYと、X.7.YYYです。 コード、サンプルテキスト、および各エントリーのための記述は[RFC3463]から取ることです。 各エントリーはG.ボードルイによって提出された参照として[RFC3463]を使用することになっています、そして、変化はIESGによって制御されました。 クラスと対象のサブコードテーブルのためのどんな関連詳細サブコード値もありません。
The initial values for the Enumerated Status Code table is to be populated from:
Enumerated Status Codeテーブルのための初期の値は以下から居住されることです。
1. sections 3.1 through 3.8 of [RFC3463], (X.0.0, X.1.0 through
X.1.8, X.2.0 through X.2.4, X.3.0 through X.3.5, X.4.0 through
X.4.7, X.5.0 through X.5.5, X.6.0 through X.6.5, and X.7.0
through X.7.7),
1. セクションの3.1〜3.8[RFC3463]と、(X.0.0、X.1.8を通したX.1.0、X.2.4を通したX.2.0、X.3.5を通したX.3.0、X.4.7を通したX.4.0、X.5.5を通したX.5.0、X.6.5を通したX.6.0、およびX.7.7を通したX.7.0)
2. section 3.3.4 of [RFC3886] (X.1.9),
2. .4セクション3.3[RFC3886](X.1.9)
3. X.6.6 found in section 5 of [RFC4468], (but not X.7.8 found in
the same section),
3. [RFC4468]のセクション5で見つけられたX.6.6、(同じセクションで見つけられたX.7.8だけでない)
4. and X.5.6, X.7.8, X.7.9, X.7.11, and X.7.12, found in section 6
of [RFC4954] (using the text from X.5.6, 5.7.8, 5.7.9, 5.7.11,
and 4.7.12).
そして、4.、[RFC4954]のセクション6で見つけられたX.5.6、X.7.8、X.7.9、X.7.11、およびX.7.12、(X.5.6からのテキストを使用する、5.7、.8、5.7 .9 5.7 .11、4.7 .12)。
Each entry is to be designated as defined in the corresponding RFC, submitted by the corresponding RFC author, and change controlled by the IESG. Each of the above RFCs is a standards-track document.
各エントリーは対応するRFC作者によって提出された対応するRFCで定義されるように指定されることになっていました、そして、変化はIESGによって制御されました。 それぞれの上のRFCsは標準化過程文書です。
The initial values for the Associated Basic Status Code for each of the above initial enhanced status codes is given in the following table.
以下のテーブルでそれぞれの上の初期の高められたステータスコードのためのAssociated Basic Status Codeのための初期の値を与えます。
As noted above, this table is incomplete. In particular, the entries that have some basic status codes might allow for other detail sub- status codes, while the entries denoted "Not given" can be filled in by updating the IANA registry through updates to this document or at the direction of the IESG.
上で述べたように、このテーブルは不完全です。 特に、いくつかの基本的なステータスコードを持っているエントリーは他の詳細サブステータスコードを考慮するかもしれません、このドキュメントへのアップデートを通して、または、IESGの方向でIANA登録をアップデートすることによって、「与えられていなく」て、指示されたエントリーに記入できますが。
Hansen & Klensin Best Current Practice [Page 5] RFC 5248 SMTP Enhanced Status Code Registry June 2008
ステータスコード登録2008年6月に高められたハンセンとKlensinの最も良い現在の習慣[5ページ]RFC5248SMTP
+--------+---------------+--------+----------+--------+-------------+ | Enh. | Assoc. Basic | Enh. | Assoc. | Enh. | Assoc. | | Status | Status Code | Status | Basic | Status | Basic | | Code | | Code | Status | Code | Status Code | | | | | Code | | | +--------+---------------+--------+----------+--------+-------------+ | X.0.0 | Any | X.1.0 | Not | X.1.1 | 451, 550 | | | | | given | | | | X.1.2 | Not given | X.1.3 | 501 | X.1.4 | Not given | | X.1.5 | 250 | X.1.6 | Not | X.1.7 | Not given | | | | | given | | | | X.1.8 | 451, 501 | X.1.9 | Not | X.2.0 | Not given | | | | | given | | | | X.2.1 | Not given | X.2.2 | 552 | X.2.3 | 552 | | X.2.4 | 450, 452 | X.3.0 | 221, | X.3.1 | 452 | | | | | 250, | | | | | | | 421, | | | | | | | 451, | | | | | | | 550, 554 | | | | X.3.2 | 453 | X.3.3 | Not | X.3.4 | 552, 554 | | | | | given | | | | X.3.5 | Not given | X.4.0 | Not | X.4.1 | 451 | | | | | given | | | | X.4.2 | 421 | X.4.3 | 451, 550 | X.4.4 | Not given | | X.4.5 | 451 | X.4.6 | Not | X.4.7 | Not given | | | | | given | | | | X.5.0 | 220, 250, | X.5.1 | 430, | X.5.2 | 500, 501, | | | 251, 252, | | 500, | | 502, 550, | | | 253, 451, | | 501, | | 555 | | | 452, 454, | | 503, | | | | | 458, 459, | | 530, | | | | | 501, 502, | | 550, | | | | | 503, 554 | | 554, 555 | | | | X.5.3 | 451 | X.5.4 | 451, | X.5.5 | Not given | | | | | 501, | | | | | | | 502, | | | | | | | 503, | | | | | | | 504, | | | | | | | 550, 555 | | | | X.5.6 | 500 | X.6.0 | Not | X.6.1 | Not given | | | | | given | | | | X.6.2 | Not given | X.6.3 | 554 | X.6.4 | 250 | | X.6.5 | Not given | X.6.6 | 554 | X.7.0 | 220, 235, | | | | | | | 450, 454, | | | | | | | 500, 501, | | | | | | | 503, 504, | | | | | | | 530, 535, | | | | | | | 550 |
+--------+---------------+--------+----------+--------+-------------+ | Enh。 | Assoc。 基本的| Enh。 | Assoc。 | Enh。 | Assoc。 | | 状態| ステータスコード| 状態| 基本的| 状態| 基本的| | コード| | コード| 状態| コード| ステータスコード| | | | | コード| | | +--------+---------------+--------+----------+--------+-------------+ | X.0.0| いくらか| X.1.0| not| X.1.1| 451, 550 | | | | | 与えます。| | | | X.1.2| 与えられていません。| X.1.3| 501 | X.1.4| 与えられていません。| | X.1.5| 250 | X.1.6| not| X.1.7| 与えられていません。| | | | | 与えます。| | | | X.1.8| 451, 501 | X.1.9| not| X.2.0| 与えられていません。| | | | | 与えます。| | | | X.2.1| 与えられていません。| X.2.2| 552 | X.2.3| 552 | | X.2.4| 450, 452 | X.3.0| 221, | X.3.1| 452 | | | | | 250, | | | | | | | 421, | | | | | | | 451, | | | | | | | 550, 554 | | | | X.3.2| 453 | X.3.3| not| X.3.4| 552, 554 | | | | | 与えます。| | | | X.3.5| 与えられていません。| X.4.0| not| X.4.1| 451 | | | | | 与えます。| | | | X.4.2| 421 | X.4.3| 451, 550 | X.4.4| 与えられていません。| | X.4.5| 451 | X.4.6| not| X.4.7| 与えられていません。| | | | | 与えます。| | | | X.5.0| 220, 250, | X.5.1| 430, | X.5.2| 500, 501, | | | 251, 252, | | 500, | | 502, 550, | | | 253, 451, | | 501, | | 555 | | | 452, 454, | | 503, | | | | | 458, 459, | | 530, | | | | | 501, 502, | | 550, | | | | | 503, 554 | | 554, 555 | | | | X.5.3| 451 | X.5.4| 451, | X.5.5| 与えられていません。| | | | | 501, | | | | | | | 502, | | | | | | | 503, | | | | | | | 504, | | | | | | | 550, 555 | | | | X.5.6| 500 | X.6.0| not| X.6.1| 与えられていません。| | | | | 与えます。| | | | X.6.2| 与えられていません。| X.6.3| 554 | X.6.4| 250 | | X.6.5| 与えられていません。| X.6.6| 554 | X.7.0| 220, 235, | | | | | | | 450, 454, | | | | | | | 500, 501, | | | | | | | 503, 504, | | | | | | | 530, 535, | | | | | | | 550 |
Hansen & Klensin Best Current Practice [Page 6] RFC 5248 SMTP Enhanced Status Code Registry June 2008
ステータスコード登録2008年6月に高められたハンセンとKlensinの最も良い現在の習慣[6ページ]RFC5248SMTP
| X.7.1 | 451, 454, | X.7.2 | 550 | X.7.3 | Not given | | | 502, 503, | | | | | | | 533, 550, 551 | | | | | | X.7.4 | 504 | X.7.5 | Not | X.7.6 | Not given | | | | | given | | | | X.7.7 | Not given | X.7.8 | 535, 554 | X.7.9 | 534 | | X.7.10 | 523 | X.7.11 | 524, 538 | X.7.12 | 422, 432 | | X.7.13 | 525 | X.7.14 | 535, 554 | | | +--------+---------------+--------+----------+--------+-------------+
| X.7.1| 451, 454, | X.7.2| 550 | X.7.3| 与えられていません。| | | 502, 503, | | | | | | | 533, 550, 551 | | | | | | X.7.4| 504 | X.7.5| not| X.7.6| 与えられていません。| | | | | 与えます。| | | | X.7.7| 与えられていません。| X.7.8| 535, 554 | X.7.9| 534 | | X.7.10| 523 | X.7.11| 524, 538 | X.7.12| 422, 432 | | X.7.13| 525 | X.7.14| 535, 554 | | | +--------+---------------+--------+----------+--------+-------------+
Table 1
テーブル1
The following additional definitions have been registered in the enumerated status code table. These entries have been used in the industry without any published specification.
列挙されたステータスコードテーブルに以下の追加定義を登録してあります。 これらのエントリーは少しも広められた仕様なしで産業に使用されました。
Code: X.7.10
Sample Text: Encryption Needed
Associated basic status code: 523
Description: This indicates that an external strong privacy
layer is needed in order to use the requested
authentication mechanism. This is primarily
intended for use with clear text authentication
mechanisms. A client that receives this may
activate a security layer such as TLS prior to
authenticating, or attempt to use a stronger
mechanism.
Reference: RFC 5248 (Best current practice)
Submitter: T. Hansen, J. Klensin
Change controller: IESG
コード: X.7.10はテキストを抽出します: 暗号化はAssociatedの基本的なステータスコードを必要としました: 523記述: これは、外部の強いプライバシー層が要求された認証機構を使用するのに必要であることを示します。 これはクリアテキスト認証機構による使用のために主として意図します。これを受けるクライアントは、認証の前のTLSなどのセキュリティ層を活性化するか、または、より強いメカニズムを使用するのを試みるかもしれません。 参照: RFC5248(最も良い現在の習慣)Submitter: T。 ハンセン、J.Klensin Changeコントローラ: IESG
Hansen & Klensin Best Current Practice [Page 7] RFC 5248 SMTP Enhanced Status Code Registry June 2008
ステータスコード登録2008年6月に高められたハンセンとKlensinの最も良い現在の習慣[7ページ]RFC5248SMTP
Code: X.7.13
Sample Text: User Account Disabled
Associated basic status code: 525
Description: Sometimes a system administrator will have to
disable a user's account (e.g., due to lack of
payment, abuse, evidence of a break-in attempt,
etc.). This error code occurs after a successful
authentication to a disabled account. This
informs the client that the failure is permanent
until the user contacts their system
administrator to get the account re-enabled. It
differs from a generic authentication failure
where the client's best option is to present the
passphrase entry dialog in case the user simply
mistyped their passphrase.
Reference: RFC 5248 (Best current practice)
Submitter: T. Hansen, J. Klensin
Change controller: IESG
コード: X.7.13はテキストを抽出します: ユーザのAccount Disabled Associatedの基本的なステータスコード: 525記述: 時々、システム管理者はユーザのアカウント(例えば、支払い、乱用、不法侵入未遂に関する証拠などの不足による)を無効にしなければならないでしょう。 このエラーコードはうまくいっている認証の後に障害があるアカウントに起こります。 これは、ユーザがアカウントを再可能にさせるために彼らのシステム管理者に連絡するまで失敗が永久的であることをクライアントに知らせます。 それはユーザが単にそれらのパスフレーズをmistypedするといけなかったのでパスフレーズエントリー対話を提示するところでクライアントの最良の選択肢がことであるジェネリック認証失敗と異なっています。 参照: RFC5248(最も良い現在の習慣)Submitter: T。 ハンセン、J.Klensin Changeコントローラ: IESG
Code: X.7.14
Sample Text: Trust relationship required
Associated basic status code: 535, 554
Description: The submission server requires a configured trust
relationship with a third-party server in order
to access the message content. This value
replaces the prior use of X.7.8 for this error
condition, thereby updating [RFC4468].
Reference: RFC 5248 (Best current practice)
Submitter: T. Hansen, J. Klensin
Change controller: IESG
コード: X.7.14はテキストを抽出します: 信頼関係はAssociatedの基本的なステータスコードを必要としました: 535、554記述: 服従サーバは、メッセージ内容にアクセスするために第三者サーバとの構成された信頼関係を必要とします。 この値はX.7.8のこのエラー条件の先の使用を取り替えて、その結果、[RFC4468]をアップデートします。 参照: RFC5248(最も良い現在の習慣)Submitter: T。 ハンセン、J.Klensin Changeコントローラ: IESG
3. Security Considerations
3. セキュリティ問題
As stated in [RFC1893], use of enhanced status codes may disclose additional information about how an internal mail system is implemented beyond that available through the SMTP status codes.
[RFC1893]に述べられているように、高められたステータスコードの使用は内部のメールシステムがどうそれを超えてSMTPステータスコードを通して利用可能な状態で導入されるかに関する追加情報を明らかにするかもしれません。
Many proposed additions to the response code list are security related. Having these registered in one place to prevent collisions will improve their value. Security error responses can leak information to active attackers (e.g., the distinction between "user not found" and "bad password" during authentication). Documents defining security error codes should make it clear when this is the case so SMTP server software subject to such threats can provide appropriate controls to restrict exposure.
応答コードリストへの多くの提案された追加が関係づけられたセキュリティです。 衝突を防ぐ1つの場所でこれらを登録させると、それらの値は改良されるでしょう。 セキュリティ誤り応答は活発な攻撃者(例えば、認証の間の「見つけられなかったユーザ」と「無効なパスワード」の区別)に情報を漏らすことができます。 セキュリティエラーコードを定義するドキュメントは、いつこれがそのような脅威を条件としたSMTPサーバーソフトウェアが暴露を制限するために適切なコントロールを提供できるようにそうであるかを断言するはずです。
Hansen & Klensin Best Current Practice [Page 8] RFC 5248 SMTP Enhanced Status Code Registry June 2008
ステータスコード登録2008年6月に高められたハンセンとKlensinの最も良い現在の習慣[8ページ]RFC5248SMTP
4. Acknowledgements
4. 承認
While the need for this registry should have become clear shortly after [RFC3463] was approved, the growth of the code table through additional documents and work done as part of email internationalization and [RFC2821] updating efforts made the requirement much more clear. The comments of the participants in those efforts are gratefully acknowledged, particularly the members of the ietf-smtp@imc.org mailing list. Chris Newman and Randy Gellens provided useful comments and some text for early versions of the document.
[RFC3463]が承認されたすぐ後にこの登録の必要性は明確になったべきでしたが、取り組みをアップデートしながらメール国際化と[RFC2821]の一部として行われた追加ドキュメントと仕事によるコードテーブルの成長は要件をはるかに明らかにしました。 それらの取り組みにおける、関係者のコメントは感謝して承諾されて、特に ietf-smtp@imc.org のメンバーはメーリングリストです。 クリス・ニューマンとランディGellensは役に立つコメントと何らかのテキストをドキュメントの早めのバージョンに提供しました。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, January 2003.
[RFC3463] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、2003年1月。
[RFC3886] Allman, E., "An Extensible Message Format for Message
Tracking Responses", RFC 3886, September 2004.
[RFC3886] オールマン、E.、「メッセージの追跡応答のための広げることができるメッセージ・フォーマット」、RFC3886、2004年9月。
[RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468,
May 2006.
[RFC4468]ニューマン(C.、「メッセージ服従節拡張子」、RFC4468)は2006がそうするかもしれません。
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
for Authentication", RFC 4954, July 2007.
[RFC4954] SiemborskiとR.とA.メリニコフ、「認証のためのSMTPサービス拡張子」、RFC4954、2007年7月。
5.2. Informative References
5.2. 有益な参照
[RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 1893, January 1996.
[RFC1893] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC1893、1996年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5226] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
Hansen & Klensin Best Current Practice [Page 9] RFC 5248 SMTP Enhanced Status Code Registry June 2008
ステータスコード登録2008年6月に高められたハンセンとKlensinの最も良い現在の習慣[9ページ]RFC5248SMTP
Authors' Addresses
作者のアドレス
Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA
トニーハンセンAT&T研究所200ローレルAve。 ミドルタウン、ニュージャージー07748米国
EMail: tony+mailesc@maillennium.att.com
メール: しゃれた+ mailesc@maillennium.att.com
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
Ave、ジョンC Klensin1770マサチューセッツSte322MA02140ケンブリッジ(米国)
Phone: +1 617 245 1457 EMail: john+ietf@jck.com
以下に電話をしてください。 +1 1457年の617 245メール: john+ ietf@jck.com
Hansen & Klensin Best Current Practice [Page 10] RFC 5248 SMTP Enhanced Status Code Registry June 2008
ステータスコード登録2008年6月に高められたハンセンとKlensinの最も良い現在の習慣[10ページ]RFC5248SMTP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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に情報を扱ってください。
Hansen & Klensin Best Current Practice [Page 11]
ハンセンとKlensinの最も良い現在の習慣[11ページ]
一覧
スポンサーリンク
