A Registry for SMTP Enhanced Mail System Status Codes
RFC 5248

[Ballot discuss]
Section 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 responsible
  party."

There is an inconsistency here. Shouldn't this text refer to the listed "change controller"?

[Ballot discuss]
Discuss Discuss:


Section 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 responsible
  party."

There is an inconsistency here. Shouldn't this text refer to the listed "change controller"?

[Ballot discuss]
Discuss Discuss:

Section 2.1: Change Controller:

"This will be "IESG" in the case of IETF-produced documents."

Shouldn't this actually be IETF? If I compare this to media types that also have a change controller field, we are generally very hesitant to specify anything else than IETF. After all IETF means that we need consensus on the change which will be judged by IESG. I think of two negative things of saying IESG. First that IESG may disappear and it would be unclear where this power goes. Secondly, that it may be interpreted that IESG has the right to say no over the community about updates.

Section 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 responsible
  party."

There is an inconsistency here. Shouldn't this text refer to the listed "change controller"?

[Ballot discuss]
Discuss Discuss:

Section 2.1: Change Controller:

"This will be "IESG" in the case of IETF-produced documents."

Shouldn't this actually be IETF? If I compare this to media types that also have a change controller field, we are generally very hesitant to specify anything else than IETF. After all IETF means that we need consensus on the change which will be judged by IESG.

[Ballot discuss]
IANA has questions:

  Extended code X.7.8 is defined in both RFC4468 and RFC4954.
  Which one should go into the registry?  It APPEARS you want
  the RFC4954 version and NOT the RFC4468 version?

  Also, IANA usually calls it a "Reference", not "Defined".
  The registry entries have been updated appropriately but
  the document should get updated to match.

  Who will fill in the "not given" information?

[Ballot comment]
A lot of draft-hansens, draft-klensins, draft-melnikovs, etc. Documents
that are discussed on specific mailing lists around a topic. I counted
over 60% individual submission rate over WG submission rate on the APPS
area. Good documents. Necessary documents. Stuff that should be done. But
are you sure you don't need more WGs? I do a lot of individual submissions
too, but I also find that WG documents do get more review, more exposure
from the IETF community, easier to delegate work to chairs, etc. Is there
something that blocks us from having more WGs to look at these things,
e.g., around e-mail? Are the updates too spread out to define a useful
WG for them? Or does our process of starting up a WG have a too high
bar?

[Ballot discuss]
The early registration procedures don't work for a document that is not a WG document. I think the easiest way to fix this would be just to use AD Approval for these.

IANA Last Call comments:

IANA has questions:

- Extended code X.7.8 is defined in both RFC4468 and RFC4954.
  Which one should go into the registry?  It APPEARS you want
  the RFC4954 version and NOT the RFC4468 version?

- Also, IANA usually calls it a "Reference", not "Defined".
  The registry entries have been updated appropriately but
  the document should get updated to match.

- Who will fill in the "not given" information?

Action 1:

Upon approval of this document, the IANA will in the following
registry "SMTP Enhanced Status Codes" located at
http://www.iana.org/assignments/REF
create a new sub-registry "Class Sub-codes"

Registration Procedures:  Specification Required

Initial Contents:

Class Sub-Code:    2.X.YYY
Summary:            Success
Description:        Success specifies that the DSN is reporting a positive
                    delivery action.  Detail sub-codes may provide
                    notification of transformations required for delivery.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Class Sub-Code:    4.X.YYY
Summary:            Persistent Transient Failure
Description:        A persistent transient failure is one in which the
                    message as sent is valid, but persistence of some
                    temporary condition has caused abandonment or
                    delay of attempts to send the message.  If this
                    code accompanies a delivery failure report,
                    sending in the future may be successful.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Class Sub-Code:    5.X.YYY
Summary:            Permanent Failure
Description:        A permanent failure is one which is not likely to be
                    resolved by resending the message in the current
                    form.  Some change to the message or the
                    destination must be made for successful delivery.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG



Action 2:

Upon approval of this document, the IANA will in the following
registry "SMTP Enhanced Status Codes" located at
http://www.iana.org/assignments/REF
create a new sub-registry "Subject Sub-codes"

Registration Procedures:  Specification Required

Initial Contents:

Subject Sub-Code:  X.0.YYY
Summary:            Other or Undefined Status
Description:        There is no additional subject information available.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Subject Sub-Code:  X.1.YYY
Summary:            Addressing Status           
Description:        The address status reports on the originator or
                    destination address.  It may include address
                    syntax or validity.  These errors can generally be
                    corrected by the sender and retried.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Subject Sub-Code:  X.2.YYY
Summary:            Mailbox Status             
Description:        Mailbox status indicates that something having to do
                    with the mailbox has caused this DSN.  Mailbox
                    issues are assumed to be under the general control
                    of the recipient.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Subject Sub-Code:  X.3.YYY
Summary:            Mail System Status         
Description:        Mail system status indicates that something having to do
                    with the destination system has caused this DSN.
                    System issues are assumed to be under the general
                    control of the destination system administrator.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Subject Sub-Code:  X.4.YYY
Summary:            Network and Routing Status 
Description:        The networking or routing codes report status about the
                    delivery system itself.  These system components
                    include any necessary infrastructure such as
                    directory and routing services.  Network issues
                    are assumed to be under the control of the
                    destination or intermediate system administrator.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Subject Sub-Code:  X.5.YYY
Summary:            Mail Delivery Protocol Status
Description:        The mail delivery protocol status codes report failures
                    involving the message delivery protocol.  These
                    failures include the full range of problems
                    resulting from implementation errors or an
                    unreliable connection.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Subject Sub-Code:  X.6.YYY
Summary:            Message Content or Media Status
Description:        The message content or media status codes report
                    failures involving the content of the message.
                    These codes report failures due to translation,
                    transcoding, or otherwise unsupported message
                    media.  Message content or media issues are under
                    the control of both the sender and the receiver,
                    both of which must support a common set of
                    supported content-types.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Subject Sub-Code:  X.7.YYY
Summary:            Security or Policy Status   
Description:        The security or policy status codes report failures
                    involving policies such as per-recipient or
                    per-host filtering and cryptographic operations.
                    Security and policy status issues are assumed to
                    be under the control of either or both the sender
                    and recipient.  Both the sender and recipient must
                    permit the exchange of messages and arrange the
                    exchange of necessary keys and certificates for
                    cryptographic operations.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Action 3:

Upon approval of this document, the IANA will in the following
registry "SMTP Enhanced Status Codes" located at
http://www.iana.org/assignments/REF
create a new sub-registry "Enumerated Status Codes"

Registration Procedures:  Specification Required

Initial Contents:


Code:              X.0.0
Sample Text:        Other undefined Status
Associated Basic Status Codes:  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:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG


Code:              X.1.0
Sample Text:        Other address status
Associated Basic Status Codes:  Not Given
Description:        Something about the address specified in the message
                    caused this DSN.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.1.1
Sample Text:        Bad destination mailbox address
Associated Basic Status Codes:  451, 550
Description:        The mailbox specified in the address does not exist.
                    For Internet mail names, this means the address
                    portion to the left of the "@" sign is invalid.
                    This code is only useful for permanent failures.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.1.2
Sample Text:        Bad destination system address
Associated Basic Status Codes:  Not Given
Description:        The destination system specified in the address does
                    not exist or is incapable of accepting mail.  For
                    Internet mail names, this means the address
                    portion to the right of the "@" is invalid for
                    mail.  This code is only useful for permanent
                    failures.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.1.3
Sample Text:        Bad destination mailbox address syntax
Associated Basic Status Codes:  501
Description:        The destination address was syntactically invalid.
                    This can apply to any field in the address.  This
                    code is only useful for permanent failures.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.1.4
Sample Text:        Destination mailbox address ambiguous
Associated Basic Status Codes:  Not Given
Description:        The mailbox address as specified matches one or more
                    recipients on the destination system.  This may
                    result if a heuristic address mapping algorithm is
                    used to map the specified address to a local
                    mailbox name.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.1.5
Sample Text:        Destination address valid
Associated Basic Status Codes:  250
Description:        This mailbox address as specified was valid.  This
                    status code should be used for positive delivery reports.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.1.6
Sample Text:        Destination mailbox has moved, No forwarding address
Associated Basic Status Codes:  Not Given
Description:        The mailbox address provided was at one time valid,
                    but mail is no longer being accepted for that
                    address.  This code is only useful for permanent
                    failures.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.1.7
Sample Text:        Bad sender's mailbox address syntax
Associated Basic Status Codes:  Not Given
Description:        The sender's address was syntactically invalid.  This
                    can apply to any field in the address.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.1.8
Sample Text:        Bad sender's system address
Associated Basic Status Codes:  451, 501
Description:        The sender's system specified in the address does
                    not exist or is incapable of accepting return
                    mail.  For domain names, this means the address
                    portion to the right of the "@" is invalid for
                    mail.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.1.9
Sample Text:        Message relayed to non-compliant mailer
Associated Basic Status Codes:  Not Given
Description:        The mailbox address specified was valid, but the
                    message has been relayed to a system that does not
                    speak this protocol; no further information can be
                    provided.
Reference:          [RFC3886] (Standards track)
Submitter:          E. Allman
Change Controller:  IESG


Code:              X.2.0
Sample Text:        Other or undefined mailbox status
Associated Basic Status Codes:  Not Given
Description:        The mailbox exists, but something about the
                    destination mailbox has caused the sending of this DSN.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.2.1
Sample Text:        Mailbox disabled, not accepting messages
Associated Basic Status Codes:  Not Given
Description:        The mailbox exists, but is not accepting messages.
                    This may be a permanent error if the mailbox will
                    never be re-enabled or a transient error if the
                    mailbox is only temporarily disabled.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.2.2
Sample Text:        Mailbox full
Associated Basic Status Codes:  552
Description:        The mailbox is full because the user has exceeded
                    a per-mailbox administrative quota or physical
                    capacity.  The general semantics implies that the
                    recipient can delete messages to make more space
                    available.  This code should be used as a
                    persistent transient failure.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.2.3
Sample Text:        Message length exceeds administrative limit
Associated Basic Status Codes:  552
Description:        A per-mailbox administrative message length limit
                    has been exceeded.  This status code should be
                    used when the per-mailbox message length limit is
                    less than the general system limit.  This code
                    should be used as a permanent failure.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.2.4
Sample Text:        Mailing list expansion problem
Associated Basic Status Codes:  450, 452
Description:        The mailbox is a mailing list address and the
                    mailing list was unable to be expanded.  This code
                    may represent a permanent failure or a persistent
                    transient failure.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG


Code:              X.3.0
Sample Text:        Other or undefined mail system status
Associated Basic Status Codes:  221, 250, 421, 451, 550, 554
Description:        The destination system exists and normally accepts
                    mail, but something about the system has caused
                    the generation of this DSN.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.3.1
Sample Text:        Mail system full
Associated Basic Status Codes:  452
Description:        Mail system storage has been exceeded.  The general
                    semantics imply that the individual recipient may
                    not be able to delete material to make room for
                    additional messages.  This is useful only as a
                    persistent transient error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.3.2
Sample Text:        System not accepting network messages
Associated Basic Status Codes:  453
Description:        The host on which the mailbox is resident is not
                    accepting messages.  Examples of such conditions
                    include an immanent shutdown, excessive load, or
                    system maintenance.  This is useful for both
                    permanent and persistent transient errors.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.3.3
Sample Text:        System not capable of selected features
Associated Basic Status Codes:  Not Given
Description:        Selected features specified for the message are
                    not supported by the destination system.  This can
                    occur in gateways when features from one domain
                    cannot be mapped onto the supported feature in
                    another.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.3.4
Sample Text:        Message too big for system
Associated Basic Status Codes:  552, 554
Description:        The message is larger than per-message size limit.
                    This limit may either be for physical or
                    administrative reasons.  This is useful only as a
                    permanent error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.3.5
Sample Text:        System incorrectly configured
Associated Basic Status Codes:  Not Given
Description:        The system is not configured in a manner that will
                    permit it to accept this message.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG


Code:              X.4.0
Sample Text:        Other or undefined network or routing status
Associated Basic Status Codes:  Not Given
Description:        Something went wrong with the networking, but it is
                    not clear what the problem is, or the problem
                    cannot be well expressed with any of the other
                    provided detail codes.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.4.1
Sample Text:        No answer from host
Associated Basic Status Codes:  451
Description:        The outbound connection attempt was not answered,
                    because either the remote system was busy, or was
                    unable to take a call.  This is useful only as a
                    persistent transient error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.4.2
Sample Text:        Bad connection
Associated Basic Status Codes:  421
Description:        The outbound connection was established, but was
                    unable to complete the message transaction, either
                    because of time-out, or inadequate connection
                    quality.  This is useful only as a persistent
                    transient error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.4.3
Sample Text:        Directory server failure
Associated Basic Status Codes:  451, 550
Description:        The network system was unable to forward the message,
                    because a directory server was unavailable.  This
                    is useful only as a persistent transient error.

                    The inability to connect to an Internet DNS server
                    is one example of the directory server failure error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.4.4
Sample Text:        Unable to route
Associated Basic Status Codes:  Not Given
Description:        The mail system was unable to determine the next hop
                    for the message because the necessary routing
                    information was unavailable from the directory
                    server.  This is useful for both permanent and
                    persistent transient errors.

                    A DNS lookup returning only an SOA (Start of
                    Administration) record for a domain name is one
                    example of the unable to route error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.4.5
Sample Text:        Mail system congestion
Associated Basic Status Codes:  451
Description:        The mail system was unable to deliver the message
                    because the mail system was congested.  This is
                    useful only as a persistent transient error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.4.6
Sample Text:        Routing loop detected
Associated Basic Status Codes:  Not Given
Description:        A routing loop caused the message to be forwarded
                    too many times, either because of incorrect
                    routing tables or a user- forwarding loop.  This
                    is useful only as a persistent transient error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.4.7
Sample Text:        Delivery time expired
Associated Basic Status Codes:  Not Given
Description:        The message was considered too old by the rejecting
                    system, either because it remained on that host
                    too long or because the time-to-live value
                    specified by the sender of the message was
                    exceeded.  If possible, the code for the actual
                    problem found when delivery was attempted should
                    be returned rather than this code.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG


Code:              X.5.0
Sample Text:        Other or undefined protocol status
Associated Basic Status Codes:  220, 250, 251, 252, 253, 451, 452, 454, 458,
                    459, 501, 502, 503, 554
Description:        Something was wrong with the protocol necessary
                    to deliver the message to the next hop and the
                    problem cannot be well expressed with any of the
                    other provided detail codes.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.5.1
Sample Text:        Invalid command
Associated Basic Status Codes:  430, 500, 501, 503, 530, 550, 554, 555
Description:        A mail transaction protocol command was issued which
                    was either out of sequence or unsupported.  This
                    is useful only as a permanent error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.5.2
Sample Text:        Syntax error
Associated Basic Status Codes:  500, 501, 502, 550, 555
Description:        A mail transaction protocol command was issued which
                    could not be interpreted, either because the
                    syntax was wrong or the command is unrecognized.
                    This is useful only as a permanent error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.5.3
Sample Text:        Too many recipients
Associated Basic Status Codes:  451
Description:        More recipients were specified for the message than
                    could have been delivered by the protocol.  This
                    error should normally result in the segmentation
                    of the message into two, the remainder of the
                    recipients to be delivered on a subsequent
                    delivery attempt.  It is included in this list in
                    the event that such segmentation is not possible.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.5.4
Sample Text:        Invalid command arguments
Associated Basic Status Codes:  451, 501, 502, 503, 504, 550, 555
Description:        A valid mail transaction protocol command was issued
                    with invalid arguments, either because the
                    arguments were out of range or represented
                    unrecognized features.  This is useful only as a
                    permanent error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.5.5
Sample Text:        Wrong protocol version
Associated Basic Status Codes:  Not Given
Description:        A protocol version mis-match existed which could not
                    be automatically resolved by the communicating parties.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.5.6
Sample Text:        Authentication Exchange line is too long
Associated Basic Status Codes:  500
Description:        This enhanced status code SHOULD be returned when
                    the server fails the AUTH command due to the
                    client sending a [BASE64] response which is longer
                    than the maximum buffer size available for the
                    currently selected SASL mechanism.  This is useful
                    for both permanent and persistent transient
                    errors.
Reference:          [RFC4954] (Standards track)
Submitter:          R. Siemborski, A. Melnikov
Change Controller:  IESG


Code:              X.6.0
Sample Text:        Other or undefined media error
Associated Basic Status Codes:  Not Given
Description:        Something about the content of a message caused it
                    to be considered undeliverable and the problem
                    cannot be well expressed with any of the other
                    provided detail codes.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.6.1
Sample Text:        Media not supported
Associated Basic Status Codes:  Not Given
Description:        The media of the message is not supported by either
                    the delivery protocol or the next system in the
                    forwarding path.  This is useful only as a
                    permanent error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.6.2
Sample Text:        Conversion required and prohibited
Associated Basic Status Codes:  Not Given
Description:        The content of the message must be converted before
                    it can be delivered and such conversion is not
                    permitted.  Such prohibitions may be the
                    expression of the sender in the message itself or
                    the policy of the sending host.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.6.3
Sample Text:        Conversion required but not supported
Associated Basic Status Codes:  554
Description:        The message content must be converted in order to
                    be forwarded but such conversion is not possible
                    or is not practical by a host in the forwarding
                    path.  This condition may result when an ESMTP
                    gateway supports 8bit transport but is not able to
                    downgrade the message to 7 bit as required for the
                    next hop.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.6.4
Sample Text:        Conversion with loss performed
Associated Basic Status Codes:  250
Description:        This is a warning sent to the sender when message
                    delivery was successfully but when the delivery
                    required a conversion in which some data was lost.
                    This may also be a permanent error if the sender
                    has indicated that conversion with loss is
                    prohibited for the message.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.6.5
Sample Text:        Conversion Failed
Associated Basic Status Codes:  Not Given
Description:        A conversion was required but was unsuccessful.
                    This may be useful as a permanent or persistent
                    temporary notification.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.6.6
Sample Text:        Message content not available
Associated Basic Status Codes:  554
Description:        The message content could not be fetched from a
                    remote system.  This may be useful as a permanent
                    or persistent temporary notification.
Reference:          [RFC4468] (Standards track)
Submitter:          C. Newman
Change Controller:  IESG


Code:              X.7.0
Sample Text:        Other or undefined security status
Associated Basic Status Codes:  220, 235, 450, 454, 500, 501, 503, 504, 530,
                    535, 550
Description:        Something related to security caused the message to be
                    returned, and the problem cannot be well expressed
                    with any of the other provided detail codes.  This
                    status code may also be used when the condition
                    cannot be further described because of security
                    policies in force.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.7.1
Sample Text:        Delivery not authorized, message refused
Associated Basic Status Codes:  451, 454, 502, 503, 533, 550, 551
Description:        The sender is not authorized to send to the destination.
                    This can be the result of per-host or
                    per-recipient filtering.  This memo does not
                    discuss the merits of any such filtering, but
                    provides a mechanism to report such.  This is
                    useful only as a permanent error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.7.2
Sample Text:        Mailing list expansion prohibited
Associated Basic Status Codes:  550
Description:        The sender is not authorized to send a message to the
                    intended mailing list.  This is useful only as a
                    permanent error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.7.3
Sample Text:        Security conversion required but not possible
Associated Basic Status Codes:  Not Given
Description:        A conversion from one secure messaging protocol to
                    another was required for delivery and such
                    conversion was not possible.  This is useful only
                    as a permanent error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.7.4
Sample Text:        Security features not supported
Associated Basic Status Codes:  504
Description:        A message contained security features such as secure
                    authentication that could not be supported on the
                    delivery protocol.  This is useful only as a
                    permanent error.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.7.5
Sample Text:        Cryptographic failure
Associated Basic Status Codes:  Not Given
Description:        A transport system otherwise authorized to validate
                    or decrypt a message in transport was unable to do
                    so because necessary information such as key was
                    not available or such information was invalid.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.7.6
Sample Text:        Cryptographic algorithm not supported
Associated Basic Status Codes:  Not Given
Description:        A transport system otherwise authorized to validate
                    or decrypt a message was unable to do so because
                    the necessary algorithm was not supported.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.7.7
Sample Text:        Message integrity failure
Associated Basic Status Codes:  Not Given
Description:        A transport system otherwise authorized to validate
                    a message was unable to do so because the message
                    was corrupted or altered.  This may be useful as a
                    permanent, transient persistent, or successful
                    delivery code.
Reference:          [RFC3463] (Standards track)
Submitter:          G. Vaudreuil
Change Controller:  IESG

Code:              X.7.8
Sample Text:        Trust relationship required
Associated Basic Status Codes:  535, 554  ???
Description:        The submission server requires a configured trust
                    relationship with a third-party server in order to
                    access the message content.
Reference:          [RFC4468] (Standards track)
Submitter:          C. Newman
Change Controller:  IESG

Code:              X.7.8
Sample Text:        Authentication credentials invalid
Associated Basic Status Codes:  545, 554  ???
Description:        This response to the AUTH command indicates that
                    the authentication failed due to invalid or
                    insufficient authentication credentials.  In this
                    case, the client SHOULD ask the user to supply new
                    credentials (such as by presenting a password
                    dialog box).
Reference:          [RFC4954] (Standards track)
Submitter:          R. Siemborski, A. Melnikov
Change Controller:  IESG

Code:              X.7.9
Sample Text:        Authentication mechanism is too weak
Associated Basic Status Codes:  534
Description:        This response to the AUTH command indicates that
                    the selected authentication mechanism is weaker
                    than server policy permits for that user.  The
                    client SHOULD retry with a new authentication
                    mechanism.
Reference:          [RFC4954] (Standards track)
Submitter:          R. Siemborski, A. Melnikov
Change Controller:  IESG

Code:              X.7.10
Sample Text:        Encryption Needed
Associated Basic Status Codes:  523
Description:        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.
Reference:          [RFC-hansen-4468upd-mailesc-registry-04]  (Standards track)
Submitter:          T. Hansen, J. Klensin
Change controller:  IESG

Code:              X.7.11
Sample Text:        Encryption required for requested authentication
Associated Basic Status Codes:  524, 538
                    mechanism
Description:        This response to the AUTH command indicates that the
                    selected authentication mechanism may only be used
                    when the underlying SMTP connection is encrypted.
                    Note that this response code is documented here
                    for historical purposes only.  Modern
                    implementations SHOULD NOT advertise mechanisms
                    that are not permitted due to lack of encryption,
                    unless an encryption layer of sufficient strength
                    is currently being employed.
Reference:          [RFC4954] (Standards track)
Submitter:          R. Siemborski, A. Melnikov
Change Controller:  IESG

Code:              X.7.12
Sample Text:        A password transition is needed
Associated Basic Status Codes:  422, 432
Description:        This response to the AUTH command indicates that
                    the user needs to transition to the selected
                    authentication mechanism.  This is typically done
                    by authenticating once using the [PLAIN]
                    authentication mechanism.  The selected mechanism
                    SHOULD then work for authentications in subsequent
                    sessions.
Reference:          [RFC4954] (Standards track)
Submitter:          R. Siemborski, A. Melnikov
Change Controller:  IESG

Code:              X.7.13
Sample Text:        User Account Disabled
Associated Basic Status Codes:  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-hansen-4468upd-mailesc-registry-04]  (Standards track)
Submitter:          T. Hansen, J. Klensin
Change controller:  IESG

Code:              X.7.14
Sample Text:        Trust relationship required
Associated Basic Status Codes:  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-hansen-4468upd-mailesc-registry-04]  (Standards track)
Submitter:          T. Hansen, J. Klensin
Change controller:  IESG

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

Harald Tveit Alvestrand

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed on the ietf-smtp mailing list,
which is the same mailing list as used for the SMTP update.
The shepherd believes that review has been adequate.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

No.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

There seems to be solid consensus that this document is needed,
and consensus that the current document is adequate.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

yes.
Note: idnits mentions one obsoleted reference. This is a
deliberate historical reference.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967].

Yes, no, irrelevant, no.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

Yes.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

Yes. There are no such sections.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

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.

Working Group Summary

This document has been reviewed on the ietf-smtp mailing list.
There have been several comments on details, which have largely
been incorporated, and substantial revisions from the first draft
to this one. No objection to the effort has been made; the
authors have been commended for undertaking the effort.

Document Quality

The document has been reviewed by the mailing list and the document
shepherd. The specific codes described here document existing
practice, except for the newly defined codes that are concerned
with resolving conflicts between multiple usages of codepoints
in present usage.