< draft-hansen-4468upd-mailesc-registry-04.txt		draft-hansen-4468upd-mailesc-registry-05.txt >
	Network Working Group T. Hansen		Network Working Group T. Hansen
	Internet-Draft AT&T Laboratories		Internet-Draft AT&T Laboratories
	Updates: 3463,4468,4954 J. Klensin		Updates: 3463,4468,4954 J. Klensin
	(if approved) February 25, 2008		(if approved) April 18, 2008
	Intended status: Standards Track		Intended status: Standards Track
	Expires: August 28, 2008		Expires: October 20, 2008
	A Registry for SMTP Enhanced Mail System Status Codes		A Registry for SMTP Enhanced Mail System Status Codes
	draft-hansen-4468upd-mailesc-registry-04		draft-hansen-4468upd-mailesc-registry-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 28, 2008.		This Internet-Draft will expire on October 20, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The specification for enhanced mail system enhanced status codes, RFC		The specification for enhanced mail system enhanced status codes, RFC
	3463, establishes a new code model and lists a collection of status		3463, establishes a new code model and lists a collection of status
	codes. While it anticipated that more codes would be added over		codes. While it anticipated that more codes would be added over
	time, it did not provide an explicit mechanism for registering and		time, it did not provide an explicit mechanism for registering and
	tracking those codes. This document specifies an IANA registry for		tracking those codes. This document specifies an IANA registry for
	mail system enhanced status codes, and initializes that registry with		mail system enhanced status codes, and initializes that registry with
	the codes so far established in published standards-track documents,		the codes so far established in published standards-track documents,
	as well as other codes that have become established in the industry.		as well as other codes that have become established in the industry.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3		2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
	2.1. SMTP Enhanced Status Codes Registry . . . . . . . . . . . 3		2.1. SMTP Enhanced Status Codes Registry . . . . . . . . . . . 3
	2.2. Review Process for New Values . . . . . . . . . . . . . . 4		2.2. Review Process for New Values . . . . . . . . . . . . . . 5
	2.3. Registration Updates . . . . . . . . . . . . . . . . . . . 5		2.3. Registration Updates . . . . . . . . . . . . . . . . . . . 5
	2.4. Initial Values . . . . . . . . . . . . . . . . . . . . . . 5		2.4. Initial Values . . . . . . . . . . . . . . . . . . . . . . 5
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 8		3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 9		5.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	5.2. Informative References . . . . . . . . . . . . . . . . . . 9		5.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . . . . 11		Intellectual Property and Copyright Statements . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Enhanced Status Codes for SMTP were first defined in [RFC1893],		Enhanced Status Codes for SMTP were first defined in [RFC1893],
	subsequently replaced by [RFC3463]. While it anticipated that more		subsequently replaced by [RFC3463]. While it anticipated that more
	codes would be added over time (see its Section 2), it did not		codes would be added over time (see its Section 2), it did not
	provide an explicit mechanism for registering and tracking those		provide an explicit mechanism for registering and tracking those
	codes. Since that time, various RFCs have been published and		codes. Since that time, various RFCs have been published and
	internet drafts proposed that define further status codes. However,		internet drafts proposed that define further status codes. However,
	without an IANA registry, conflicts in definitions have begun to		without an IANA registry, conflicts in definitions have begun to
	appear.		appear.
	This RFC defines such an IANA registry and was written to help		This RFC defines such an IANA registry and was written to help
	prevent further conflicts from appearing in the future. It		prevent further conflicts from appearing in the future. It
	initializes the registry with the established standards-track		initializes the registry with the established standards-track
	enhanced status codes from [RFC3463], [RFC3886], [RFC4468] and		enhanced status codes from [RFC3463], [RFC3886], [RFC4468] and
	[RFC4954]. In addition, several codes are added that were		[RFC4954]. In addition, several codes are added that were
	established by various internet drafts and have come into common use,		established by various internet drafts and have come into common use,
	despite the expiration of the documents themselves.		despite the expiration of the documents themselves.
	NOTE: The values given in Table 1 below are incomplete. The entries		As specified in [RFC3463], an enhanced status code consists of a
	denoted "Not given" should be filled in better. (RFC EDITOR NOTE:		three-part code, with each part being numeric and separated by a
	Remove this paragraph on publication.)		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 a XXX, and a wildcard for a
			detail sub-code is represented by an 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.)
	This document is being discussed on the SMTP mailing list,		This document is being discussed on the SMTP mailing list,
	ietf-smtp@imc.org. (RFC EDITOR NOTE: Remove this paragraph on		ietf-smtp@imc.org. (RFC EDITOR NOTE: Remove this paragraph on
	publication.)		publication.)
	2. IANA Considerations		2. IANA Considerations
	2.1. SMTP Enhanced Status Codes Registry		2.1. SMTP Enhanced Status Codes Registry
	IANA is directed to create the registry "SMTP Enhanced Status Codes".		IANA is directed to create the registry "SMTP Enhanced Status Codes".
	The Mail Enhanced Status Codes registry will have three tables:		The Mail Enhanced Status Codes registry will have three tables:
	o class sub-code,		o Class Sub-Codes. Each of the entries in this table represent
	o subject sub-code, and		class sub-codes and all have an unspecified subject sub-code and
	o enumerated status codes, which have an unspecified class sub-code,		an unspecified detail sub-code.
	a specified subject sub-code, and a specified detail sub-code.
			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 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.
	Each entry in the tables will include the following. (The sub-code		Each entry in the tables will include the following. (The sub-code
	tables will not have the Associated Basic Status Code entries.)		tables will not have the Associated Basic Status Code entries.)
	Code: The sub-code or enumerated status code,		Code: The status code. For example,
	which will be a numeric code consisting		3.XXX.YYY is a class sub-code with an
	of three components, as specified in		unspecified subject sub-code and an
	[RFC3463].		unspecified detail sub-code, and X.5.0
			is an enumerated status code with an
			unspecified class sub-code.
	Summary: or Sample Text: For class and subject sub-codes, this		Summary: or Sample Text: For class and subject sub-codes, this
	is the summary of the use for the sub-		is the summary of the use for the sub-
	code shown in section 2 of [RFC3463].		code shown in section 2 of [RFC3463].
	For enumerated status codes, this is an		For enumerated status codes, this is an
	example of a message that might be sent		example of a message that might be sent
	along with the code.		along with the code.
	Associated Basic Status Code: For enumerated status codes, the basic		Associated Basic Status Code: For enumerated status codes, the basic
	status code(s) of [RFC2821] with which		status code(s) of [RFC2821] with which
	it is usually associated. This may		it is usually associated. This may
	also have a value such as "Any" or "Not		also have a value such as "Any" or "Not
	given". NOTE: This is a non-exclusive		given". NOTE: This is a non-exclusive
	list.		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.
	Description: A short description of the code.		Description: A short description of the code.
	Defined: A reference to the document in which		Reference: A reference to the document in which
	the code is defined. This reference		the code is defined. This reference
	should note whether the relevant		should note whether the relevant
	specification is standards-track or not		specification is standards-track or not
	using "(Standards track)" or "(Not		using "(Standards track)" or "(Not
	standards track)".		standards track)".
	Submitter: The identity of the submitter, usually		Submitter: The identity of the submitter, usually
	the document author.		the document author.
	Change Controller: The identity of the change controller		Change Controller: The identity of the change controller
	for the specification. This will be		for the specification. This will be
	"IESG" in the case of IETF-produced		"IESG" in the case of IETF-produced
	documents.		documents.
	An example of an entry in the enumerated status code table would be:		An example of an entry in the enumerated status code table would be:
	Code: X.0.0		Code: X.0.0
	Sample Text: Other undefined Status		Sample Text: Other undefined Status
	Associated basic status code: Any		Associated basic status code: Any
	Description: Other undefined status is the only undefined		Description: Other undefined status is the only undefined
	error code. It should be used for all errors for		error code. It should be used for all errors for
	which only the class of the error is known.		which only the class of the error is known.
	Defined: RFC 3463. (Standards track)		Reference: RFC 3463. (Standards track)
	Submitter: G. Vaudreuil		Submitter: G. Vaudreuil
	Change controller: IESG.		Change controller: IESG.
	2.2. Review Process for New Values		2.2. Review Process for New Values
	Entries in this registry are expected to follow the "Specification		Entries in this registry are expected to follow the "Specification
	Required" model ([RFC2434]) although, in practice, most entries are		Required" model ([RFC2434]) although, in practice, most entries are
	expected to derive from standards-track documents. Non-standards-		expected to derive from standards-track documents. Non-standards-
	track documents that specify codes to be registered should be readily		track documents that specify codes to be registered should be readily
	available. The principal purpose of this registry is to avoid		available. The principal purpose of this registry is to avoid
	skipping to change at page 5, line 22 ¶		skipping to change at page 5, line 49 ¶
	standards-track entries may be updated by the listed responsible		standards-track entries may be updated by the listed responsible
	party. Only the entry's short description or references may be		party. Only the entry's short description or references may be
	modified in this way, not the code or associated text. In		modified in this way, not the code or associated text. In
	exceptional cases, any aspect of any registered entity may be updated		exceptional cases, any aspect of any registered entity may be updated
	at the direction of the IESG (for example, to correct a conflict).		at the direction of the IESG (for example, to correct a conflict).
	2.4. Initial Values		2.4. Initial Values
	The initial values for the class and subject sub-code tables are to		The initial values for the class and subject sub-code tables are to
	be populated from section 2 of [RFC3463]. Specifically, these are		be populated from section 2 of [RFC3463]. Specifically, these are
	the values for 2.X.XXX, 4.X.XXX and 5.X.XXX for the class sub-code		the values for 2.XXX.YYY, 4.XXX.YYY and 5.XXX.YYY for the Class Sub-
	table, and the values X.0.XXX, X.1.XXX, X.2.XXX, X.3.XXX, X.4.XXX,		Code table, and the values X.0.YYY, X.1.YYY, X.2.YYY, X.3.YYY,
	X.5.XXX, X.6.XXX and X.7.XXX for the subject sub-code table. The		X.4.YYY, X.5.YYY, X.6.YYY and X.7.YYY for the Subject Sub-Code table.
	code, sample text and description for each entry are to be taken from		The code, sample text and description for each entry are to be taken
	[RFC3463]. Each entry is to be designated as defined in [RFC3463],		from [RFC3463]. Each entry is to use [RFC3463] as the reference,
	submitted by G. Vaudreuil, and change controlled by IESG. There are		submitted by G. Vaudreuil, and change controlled by IESG. There are
	no associated basic status code values for the class and subject sub-		no associated detail sub-code values for the class and subject sub-
	code tables.		code tables.
	The initial values for the enumerated status code table is to be		The initial values for the Enumerated Status Code table is to be
	populated from:		populated from:
	1. sections 3.1 through 3.8 of [RFC3463], (X.0.0, X.1.0 through		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.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		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)		through X.7.7)
	2. section 3.3.4 of [RFC3886] (X.1.9),		2. section 3.3.4 of [RFC3886] (X.1.9),
	3. X.6.6 found in section 5 of [RFC4468],		3. X.6.6 found in section 5 of [RFC4468], (but not X.7.8 found in
			the same section),
	4. and X.5.6, X.7.8, X.7.9, X.7.11 and X.7.12, found in section 6 of		4. and X.5.6, X.7.8, X.7.9, X.7.11 and X.7.12, found in section 6 of
	[RFC4954].		[RFC4954].
	Each entry is to be designated as defined in the corresponding RFC,		Each entry is to be designated as defined in the corresponding RFC,
	submitted by the corresponding RFC author, and change controlled by		submitted by the corresponding RFC author, and change controlled by
	the IESG. Each of the above RFCs is a standards track document.		the IESG. Each of the above RFCs is a standards track document.
	The initial values for the Associated Basic Status Code for each of		The initial values for the Associated Basic Status Code for each of
	the above initial enhanced status codes is given in the following		the above initial enhanced status codes is given in the following
	table.		table.
	NOTE: This table is incomplete. The entries denoted "Not given"		As noted above, this table is incomplete. In particular, the entries
	should be filled in better. (RFC EDITOR NOTE: Remove this note on		that have some basic status codes might allow for other detail sub-
	publication.)		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.
	+--------+---------+--------+-------------+--------+----------------+		+--------+---------+--------+-------------+--------+----------------+
	| Enh. | Assoc. | Enh. | Assoc. | Enh. | Assoc. Basic |		| Enh. | Assoc. | Enh. | Assoc. | Enh. | Assoc. Basic |
	| Status | Basic | Status | Basic | Status | Status Code |		| Status | Basic | Status | Basic | Status | Status Code |
	| Code | Status | Code | Status Code | Code | |		| Code | Status | Code | Status Code | Code | |
	| | Code | | | | |		| | Code | | | | |
	+--------+---------+--------+-------------+--------+----------------+		+--------+---------+--------+-------------+--------+----------------+
	| X.0.0 | Any | X.1.0 | Not given | X.1.1 | 451, 550 |		| X.0.0 | Any | X.1.0 | Not given | X.1.1 | 451, 550 |
	| X.1.2 | Not | X.1.3 | 501 | X.1.4 | Not given |		| X.1.2 | Not | X.1.3 | 501 | X.1.4 | Not given |
	| | given | | | | |		| | given | | | | |
	skipping to change at page 7, line 40 ¶		skipping to change at page 8, line 37 ¶
	Sample Text: Encryption Needed		Sample Text: Encryption Needed
	Associated basic status code: 523		Associated basic status code: 523
	Description: This indicates that external strong privacy layer		Description: This indicates that external strong privacy layer
	is needed in order to use the requested		is needed in order to use the requested
	authentication mechanism. This is primarily		authentication mechanism. This is primarily
	intended for use with clear text authentication		intended for use with clear text authentication
	mechanisms. A client which receives this may		mechanisms. A client which receives this may
	activate a security layer such as TLS prior to		activate a security layer such as TLS prior to
	authenticating, or attempt to use a stronger		authenticating, or attempt to use a stronger
	mechanism.		mechanism.
	Defined: RFC XXXX. (Standards track)		Reference: RFC XXXX. (Standards track)
	Submitter: T. Hansen, J. Klensin		Submitter: T. Hansen, J. Klensin
	Change controller: IESG.		Change controller: IESG.
	Code: X.7.13		Code: X.7.13
	Sample Text: User Account Disabled		Sample Text: User Account Disabled
	Associated basic status code: 525		Associated basic status code: 525
	Description: Sometimes a system administrator will have to		Description: Sometimes a system administrator will have to
	disable a user's account (e.g., due to lack of		disable a user's account (e.g., due to lack of
	payment, abuse, evidence of a break-in attempt,		payment, abuse, evidence of a break-in attempt,
	etc). This error code occurs after a successful		etc). This error code occurs after a successful
	authentication to a disabled account. This		authentication to a disabled account. This
	informs the client that the failure is permanent		informs the client that the failure is permanent
	until the user contacts their system		until the user contacts their system
	administrator to get the account re-enabled. It		administrator to get the account re-enabled. It
	differs from a generic authentication failure		differs from a generic authentication failure
	where the client's best option is to present the		where the client's best option is to present the
	passphrase entry dialog in case the user simply		passphrase entry dialog in case the user simply
	mistyped their passphrase.		mistyped their passphrase.
	Defined: RFC XXXX. (Standards track)		Reference: RFC XXXX. (Standards track)
	Submitter: T. Hansen, J. Klensin		Submitter: T. Hansen, J. Klensin
	Change controller: IESG.		Change controller: IESG.
	Code: X.7.14		Code: X.7.14
	Sample Text: Trust relationship required		Sample Text: Trust relationship required
	Associated basic status code: 535, 554		Associated basic status code: 535, 554
	Description: The submission server requires a configured trust		Description: The submission server requires a configured trust
	relationship with a third-party server in order		relationship with a third-party server in order
	to access the message content. This value		to access the message content. This value
	replaces the prior use of X.7.8 for this error		replaces the prior use of X.7.8 for this error
	condition. thereby updating [RFC4468].		condition. thereby updating [RFC4468].
	Defined: RFC XXXX. (Standards track)		Reference: RFC XXXX. (Standards track)
	Submitter: T. Hansen, J. Klensin		Submitter: T. Hansen, J. Klensin
	Change controller: IESG.		Change controller: IESG.
	3. Security Considerations		3. Security Considerations
	As stated in [RFC1893], use of enhanced status codes may disclose		As stated in [RFC1893], use of enhanced status codes may disclose
	additional information about how an internal mail system is		additional information about how an internal mail system is
	implemented beyond that available through the SMTP status codes.		implemented beyond that available through the SMTP status codes.
	Many proposed additions to the response code list are security		Many proposed additions to the response code list are security
	skipping to change at page 11, line 44 ¶		skipping to change at line 467 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 22 change blocks.
	45 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/