One document matched: draft-hansen-4468upd-mailesc-registry-03.xml
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1893 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1893.xml'>
<!ENTITY rfc2821 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2821.xml'>
<!ENTITY rfc2434 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml'>
<!ENTITY rfc3463 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3463.xml'>
<!ENTITY rfc3886 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3886.xml'>
<!ENTITY rfc4020 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4020.xml'>
<!ENTITY rfc4468 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4468.xml'>
<!ENTITY rfc4954 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4954.xml'>
]>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='no'?>
<?rfc linkmailto='no'?>
<?rfc compact='no'?>
<?rfc comments='yes'?>
<?rfc inline="yes"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc ipr='full3978'
updates='3463,4468,4954' category='std' >
<front>
<title abbrev='SMTP Enhanced Status Code Registry'>A Registry for SMTP Enhanced Mail System Status Codes</title>
<author initials='T.' surname='Hansen' fullname='Tony Hansen'>
<organization>AT&T Laboratories</organization>
<address>
<postal>
<street>200 Laurel Ave.</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<email>tony+mailesc@maillennium.att.com</email>
</address>
</author>
<author fullname="John C Klensin" initials="J.C." surname="Klensin">
<organization/>
<address>
<postal>
<street>1770 Massachusetts Ave, Ste 322</street>
<city>Cambridge</city> <region>MA</region>
<code>02140</code>
<country>USA</country>
</postal>
<phone>+1 617 245 1457</phone>
<email>john+ietf@jck.com</email>
</address>
</author>
<date year='2008' />
<area>Applications</area>
<keyword>SMTP</keyword>
<keyword>Status Codes</keyword>
<abstract>
<t>
The specification for enhanced mail system enhanced 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.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
Enhanced Status Codes for SMTP were first defined in <xref target='RFC1893' />,
subsequently replaced by <xref target='RFC3463'/>.
While it anticipated that more codes would be added
over time (see its Section 2), it did not provide an
explicit mechanism for
registering and tracking those codes.
Since that time, various RFCs have been published and internet drafts proposed
that define further status codes.
However, without an IANA registry, conflicts in definitions have begun to appear.
</t>
<t>
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 <xref target='RFC3463'/>, <xref target='RFC3886'/>, <xref target='RFC4468'/> and <xref target='RFC4954'/>.
In addition, several codes are added that were established by various internet drafts
and have come into common use, despite the expiration of the documents themselves.
</t>
<t>
NOTE: The values given in <xref target='Associated-basic-status-codes'/> below are incomplete.
</t>
<t>
This document is being discussed on the SMTP mailing list, ietf-smtp@imc.org.
(RFC EDITOR NOTE: Remove this paragraph on publication.)
</t>
</section>
<section title='IANA Considerations'>
<section title='SMTP Enhanced Status Codes Registry'>
<t>
IANA is directed to create the registry "SMTP Enhanced Status Codes".
The Mail Enhanced Status Codes registry will have three tables:
<list style='symbols'>
<t>
class sub-code,
</t>
<t>
subject sub-code, and
</t>
<t>
enumerated status codes, which include both a subject sub-code and a detail sub-code.
</t>
</list>
</t>
<t>
Each entry in the tables will include:
<list style="numbers">
<t>The sub-code or enumerated status code,
which will be a numeric code consisting of three components, as
specified in RFC 3463.
</t>
<t>
Text expected to be associated with the code.
</t>
<t>
If applicable, the basic status code of RFC 2821
<xref target="RFC2821"/> with which it is usually associated.
</t>
<t>
A short description of the code.
</t>
<t>
A reference to the document in which the code is defined.
This reference should note whether the relevant specification is standards-track or not.
</t>
<t>
The identity of the submitter, usually the document author.
</t>
<t>
The identity of the owner for the specification.
This will be "IESG" in the case of IETF-produced documents.
</t>
</list>
</t>
<t>
An example of an entry in the enumerated status code table would be:<vspace/>
<list style='hanging'>
<t hangText='X.0.0 Other undefined Status'>
<vspace/>
Associated basic status code: any
<vspace/>
Other undefined status is the only undefined error code.
<vspace/>
X.0.0 should be used for all errors for which only the class of the
error is known.
</t><t hangText=''>
Defined in RFC 3463.
</t><t hangText=''>
Submitter: G. Vaudreuil
</t><t hangText=''>
Owner: IESG.
</t>
</list>
</t>
</section>
<section title="Review Process for New Values">
<t>
Entries in this registry are expected to follow
the "Specification Required" model (<xref target='RFC2434'/>) although, in practice,
most entries are expected to derive from standards-track
documents.
However, any review process for
non-standards-track documents SHOULD accept evidence of
significant deployment as a persuasive argument that the
registration should be permitted: the principal purpose of
this registry is to avoid confusion and
conflicts among different definitions or uses for
the same code.
</t>
<t>
The procedures from <xref target='RFC4020'/> may be followed to pre-allocate an
Enhanced Status Code before final publication of an internet draft.
</t>
</section>
<section title="Registration Updates">
<t>
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 responsible party.
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).
</t>
</section>
<section title="Initial Values">
<t>
The initial values for the class and subject sub-code tables is to be populated from section 2 of <xref target='RFC3463'/>.
Specifically, these are the values for 2.XXX.XXX, 4.XXX.XXX and 5.XXX.XXX for the class sub-code table,
and the values X.0.XXX, X.1.XXX, X.2.XXX, X.3.XXX, X.4.XXX, X.5.XXX, X.6.XXX and X.7.XXX for the subject sub-code table.
Each entry is to be designated as defined in <xref target='RFC3463'/>, submitted by G. Vaudreuil, and owned by IESG.
</t>
<t>
The initial values for the enumerated status code table is to be populated from:
<list style='numbers'>
<t>
sections 3.1 through 3.8 of <xref target='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,
</t>
<t>
X.5.0 through X.5.5, X.6.0 through X.6.5, and X.7.0 through X.7.7)
section 3.3.4 of <xref target='RFC3886'/> (X.1.9),
</t>
<t>
X.6.6 found in section 5 of <xref target='RFC4468'/>,
</t>
<t>
and X.5.6, X.7.8, X.7.9, X.7.11 and X.7.12, found in section 6 of <xref target='RFC4954'/>.
</t>
</list>
Each entry is to be designated as defined in the corresponding RFC,
submitted by the corresponding RFC author, and
owned by the IESG.
</t>
<t>
The initial values for the Associated Basic Status Code for each of
the above initial enhanced status codes is given in the following table.
<vspace/>NOTE: this table is incomplete.
</t>
<texttable anchor='Associated-basic-status-codes'>
<ttcol>Enhanced Status Code</ttcol> <ttcol>Associated Basic Status Code</ttcol>
<ttcol>Enhanced Status Code</ttcol> <ttcol>Associated Basic Status Code</ttcol>
<c>X.0.0</c> <c>any</c>
<c>X.1.0</c> <c>???</c>
<c>X.1.1</c> <c>???</c>
<c>X.1.2</c> <c>???</c>
<c>X.1.3</c> <c>???</c>
<c>X.1.4</c> <c>???</c>
<c>X.1.5</c> <c>250</c>
<c>X.1.6</c> <c>???</c>
<c>X.1.7</c> <c>???</c>
<c>X.1.8</c> <c>???</c>
<c>X.2.0</c> <c>???</c>
<c>X.2.1</c> <c>???</c>
<c>X.2.2</c> <c>552</c>
<c>X.2.3</c> <c>???</c>
<c>X.2.4</c> <c>???</c>
<c>X.3.0</c> <c>???</c>
<c>X.3.1</c> <c>???</c>
<c>X.3.2</c> <c>???</c>
<c>X.3.3</c> <c>???</c>
<c>X.3.4</c> <c>554</c>
<c>X.3.5</c> <c>???</c>
<c>X.4.0</c> <c>???</c>
<c>X.4.1</c> <c>451</c>
<c>X.4.2</c> <c>???</c>
<c>X.4.3</c> <c>???</c>
<c>X.4.4</c> <c>???</c>
<c>X.4.5</c> <c>???</c>
<c>X.4.6</c> <c>???</c>
<c>X.4.7</c> <c>???</c>
<c>X.5.0</c> <c>250, 554, 503</c>
<c>X.5.1</c> <c>???</c>
<c>X.5.2</c> <c>???</c>
<c>X.5.3</c> <c>???</c>
<c>X.5.4</c> <c>???</c>
<c>X.5.5</c> <c>???</c>
<c>X.5.6</c> <c>500</c>
<c>X.6.0</c> <c>???</c>
<c>X.6.1</c> <c>???</c>
<c>X.6.2</c> <c>???</c>
<c>X.6.3</c> <c>554</c>
<c>X.6.4</c> <c>250</c>
<c>X.6.5</c> <c>???</c>
<c>X.6.6</c> <c>554</c>
<c>X.7.0</c> <c>235, 454, 530, 554</c>
<c>X.7.1</c> <c>550</c>
<c>X.7.2</c> <c>???</c>
<c>X.7.3</c> <c>???</c>
<c>X.7.4</c> <c>???</c>
<c>X.7.5</c> <c>???</c>
<c>X.7.6</c> <c>???</c>
<c>X.7.7</c> <c>???</c>
<c>X.7.8</c> <c>554, 535</c>
<c>X.7.9</c> <c>534</c>
<c>X.7.11</c> <c>538</c>
<c>X.7.12</c> <c>432</c>
</texttable>
<t>
The following additional definitions are to be registered in the enumerated status code table.
(RFC EDITOR NOTE: change XXXX below to this document's RFC number.)
<list style='hanging'>
<t hangText="X.7.10 Encryption Needed">
<vspace/>
Associated basic status code: ???
<vspace/>
This indicates that 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 which receives this may activate a security layer such as
TLS prior to authenticating, or attempt to use a stronger mechanism.
<vspace/>Defined: RFC XXXX.
<vspace/>Submitter: T. Hansen, J. Klensin
<vspace/>Owner: IESG.
</t>
<t hangText="X.7.13 User Account Disabled">
<vspace/>
Associated basic status code: ???
<vspace/>
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.
<vspace/>Defined: RFC XXXX.
<vspace/>Submitter: T. Hansen, J. Klensin
<vspace/>Owner: IESG.
</t>
<t hangText='X.7.14 Trust relationship required'>
<vspace/>
Associated basic status code: ???
<vspace/>
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 <xref target='RFC4468'/>.
<vspace/>Defined: RFC XXXX.
<vspace/>Submitter: T. Hansen, J. Klensin
<vspace/>Owner: IESG.
</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations">
<t>
As stated in <xref target='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.
</t>
<t>
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.
</t>
</section>
<section title='Acknowledgements'>
<t>
While the need for this registry should have become clear shortly after
<xref target='RFC3463'/> was approved, the growth of the code table
through additional documents and work done as part of email
internationalization and <xref target='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.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc3463;
&rfc2821;
&rfc3886;
&rfc4020;
&rfc4468;
&rfc4954;
</references>
<references title='Informative References'>
&rfc1893;
&rfc2434;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:00:11 |