Extended status codes (SMTP)

[Leer este post en español]

The different situations that can be described with the main smtp status codes defined in RFC 2821 are not enough to consider the wide range of situations an MTA server may face when delivering a message. Because of this, a new set of codes were created. The following is an extract from RFC 3463, where a definition for this new SMTP Protocol feature is given:

   SMTP error codes have historically been used for reporting mail 
   system errors.  Because of limitations in the SMTP code design,
   these are not suitable for use in delivery status notifications.
   SMTP provides about 12 useful codes for delivery reports.  The
   majority of the codes are protocol specific response codes such as
   the 354 response to the SMTP data command.  Each of the 12 useful
   codes are overloaded to indicate several error conditions.  SMTP
   suffers some scars from history, most notably the unfortunate damage
   to the reply code extension mechanism by uncontrolled use.  This
   proposal facilitates future extensibility by requiring the client to
   interpret unknown error codes according to the theory of codes while
   requiring servers to register new response codes.

This feature is known as DSN (Delivery Status Notification) codes.

When we study the structure of this new set of codes we can appreciate its versatility and the way it can extend the earlier codes. We’ll begin with the structure that must be followed when constructing the codes:

The syntax of the new status codes is defined as:

status-code = class “.” subject “.” detail
class = “2″/”4″/”5″
subject = 1*3digit
detail = 1*3digit

________________________________________________________________________

The “class” parameter defines the general category a specific code can belong to. This can be 2-Success, 4-Temporary failure and 5-Permanent failure. Its definition according to the RFC is the following:
      2.XXX.XXX   Success

Success means the DSN is reporting a successful delivery. The following sub-codes may notify any required transformation for the delivery.

      4.XXX.XXX  Persistent Transitory Failure

A persistent transitory failure is one in which the message is considered to be valid in the original form it was transmitted, but the persistance of some temporary condition has provoked the abortion or delay in the retries to deliver the message. This code usually comes in the non-delivery-response report. Sending the same mail in the future may end in a successful delivery. This kind of codes force the sending MTA server to queue the message until it is successfully delivered or its time to live has timed out, usually this value is set between 1 to 5 days.

      5.XXX.XXX   Permanent Failure

A permanent failure is one that is not expected to be solved by sending the mail in its original form. Some changes must be made to the mail or in the destination for a successful delivery. In this case, the sending MTA server should not queue the message, but delete it from its queue and send back an NDR (Non-Delivery-Response) to the sender, informing of such error.

________________________________________________________________________

The “subject” parameter specifies the notification status. The meaning of this value applies the same for any of the three types of classes defined above.

The values for “subject” may be:
      X.0.XXX   Undefined status

No additional information available.

      X.1.XXX Address status

This refers to the sender or recipient mailbox syntax. It may include address validation or syntax issues. These errors can be usually corrected by the sender and try the delivery again in the future.

      X.2.XXX Mailbox Status

This indicates a situation refering to the actual mailbox that generated this DSN. These situation fall under the recipient control, so the sender may not be able to fix the problem.

      X.3.XXX Mail System Status

This indicates that some situation on the recipient’s Mail system has caused this DSN. These situations are considered under the mail administrator of the destination mail system.

      X.4.XXX Network and routing status

These codes refer to the destination network status. The components of this system may include any necessary infrastructure like directory and routing services. It is assumed that these issues fall under the responsibility of the destination or intermediary network administrator.

      X.5.XXX Mail Delivery Protocol status

This code reports failures that involve the mail delivery protocol. These may include any implementation errors or un-trusted network connections.

      X.6.XXX Format or mail content status

This code reports failures that involve the content of the mail. These may be due to translations, decode actions or any un-supported mail format. These problems are assumed to be under the responsibility of both sender and recipient, making clear that both must support a common set of formats or file types defined in the MIME content-type header.

      X.7.XXX Policy or Security status

These codes report failures that involve policies like recipient or server filters and cryptographic operations. These problems may be the responsibility of  both sender and recipient. Both must also allow the mail transaction and prepare the key exchange processes and necessary certificates for these kind of operations.

 

_____________________________________________________________________

The “detail” parameter specifies with more detail the particular situation that reports the status code. This value applies to all of the “subject” values.

The possible values of “detail” are:
3.1 Undefined and other status
X.0.0   Any undefined status
This is the only undefined status. It must be used for all errors for which only the error class is known.

Example:
C> RSET
S> 250 2.0.0 user Resetting
or
S> 250 2.0.0 Resetting

This code is very common after the execution of the RSET command. Such command is used to indicate the SMTP Server (the server receiving the mail) to ignore any previous information and to clean all its buffers to receive a completely new mail.

 

3.2 Address status
X.1.0   Other address status
Something about the specified address in the mail has caused this DSN.

Example:
C> MAIL FROM:<user@dominio.com>
S> 250 2.1.0 user@dominio.com…Sender OK

In this example you can see this code indicating the mailbox is being accepted by the SMTP Server because it successfully satisfies the mailbox syntax.

 

X.1.1   Bad recipient mailbox address
The specified mailbox doesn’t exist. For Internet mailbox syntax this indicates the left portion from the “@” symbol is invalid. This error is useful with permanent failures.

Example:
C> RCPT TO:<asdf@dominio.com>
S> 550 5.1.1 <asdf>: Recipient address rejected: User unknown in local recipient table

Another example:

550 5.1.1 unknown or illegal alias:user@domain.com (in reply to RCPT TO command)

Both examples reflect a situation in which the mailbox or the alias name don’t exist or were deleted from the SMTP Server. This is a very typical Postfix error where the destination mailbox doesn’t exist. This can also happen when the user did exist but the associated alias is not yet available in the Postfix alias table, this is why the mail gets rejected.

 

X.1.2   Destination system address unknown
The destination system specified in the mailbox address doesn’t exist or it is not capable to accept mail at the moment. For Internet names, this means the right portion from “@” symbol is not valid for delivering mail. This code is useful for permanent failures.

 

X.1.3   Bad mailbox address syntax
The destination address has a syntax error. This may apply to any portion in the mailbox. this code is useful for permanent failures.

Example:
C> RCPT TO:<asdf@#(.com>
S> 501 5.1.3 Bad recipient address syntax

This situation can only be resolved by the sender, there’s nothing the receiving server can do to solve the problem because the mailbox syntax cannot be interpreted as valid.

 

X.1.4  Ambiguous destination mailbox address
The mailbox address as specified matches one or more recipients in the destination system. This may be the result of heuristic mapping algorithms for local mailbox addresses.

 

X.1.5   Valid destination address
The mailbox address as specified was valid. This status code should be used in successful delivery reports.

Example:
C> RCPT TO:<user@dominio.com>
S> 250 2.1.5 user@dominio.com

 

X.1.6   Destination mailbox moved, no resent address
The mailbox address was valid at some point, but is no longer receiving mail. This code is useful with permanent failures.

 

X.1.7   Bad sender mailbox address syntax
The sender’s address has a bad syntax. This code may apply to any portion of the address.

Example:
C> MAIL FROM:<kd#”.>
S> 501 5.1.7 Bad sender address syntax

 

X.1.8   Bad sender system address
The sender system specified in the address doesn’t exist or is not capable of receiving mail. For Internet domain names, this field means the portion to the right of the “@” symbol is invalid.

Example:
C> MAIL FROM:<user@kdislskdisl.com>
S> 450 4.1.8 <user@kdislskdisl.com>: Sender address rejected: Domain not found

These kind of errors may happen when the SMTP Server has a filter like the PTR record validation enabled to make sure the sender’s domain actually exists. Enabling these type of filters is not recommended because not all Internet mail servers use an actual registered FQDN, this condition may result in the rejection of valid mail.

 

3.3 Mailbox Status
X.2.0   Undefined mailbox status and others
The mailbox exists but something in the destination mailbox has caused this DSN.

 

X.2.1   Disabled mailbox, not accepting incoming mail
The mailbox does exists, but it is not accepting mails at the moment. This may indicate both a permanent failure if the mailbox is not intended to be enabled in the future or a transient failure if the mailbox is just temporarily disabled.

Example:

550 5.2.1 user disabled; cannot receive new mail: user@domain.com (in reply to RCPT TO command)

A reason for this condition is that maybe the user no longer works the company and his accounts where temporarily disabled until the separation process ends. And of course, it can also happen that the user actually left the company a while ago but the mail administrator forgot to erase the account :)

 

X.2.2   Mailbox is full
Mailbox is full because the user has exceded the authorized quota. This is usually associated with transient failures because the recipient may delete mails to free up space, and then it will be able to receive mail again.

451 4.2.2 user over quota; cannot receive new mail: user@domain.com (in reply to RCPT TO command)

The only solution to this condition is for the mail administrator to increase the user’s quota or for the user to delete mails to free up space. The sender can’t do anything to resolve this problem.

 

X.2.3   Message length exceeds administrative limit
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.

 

X.2.4   Mailing list expansion problem
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.

 

 

3.4  Mail system status
X.3.0   Mail system status undefined and others
The destination mail system does exist and normally receives mail, but something related to the system has caused this DSN.

 

X.3.1   Mail system full
The storage capacity of the mail system is exceeded. The general semantics imply that one recipient alone won’t be able to free enough space to make room for new mails. This code is useful in temporary errors.

 

X.3.2   System not accepting network messages
The host on which the mailbox is resident is not accepting messages.  Examples of such conditions include an imminent shutdown, excessive load, or system maintenance.  This is useful for both permanent and persistent transient errors.

 

X.3.3   System not capable of selected features
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.

 

X.3.4   Message is too big for the system
Mail is bigger than the mail size limit implemented by the mail server. This limit may be imposed for physical or administrative reasons. This code is useful only with permanent errors.

Example:
C> MAIL FROM:user@domain.com SIZE=9999999999
S> 552 5.3.4 Message size exceeds file system imposed limit

In this case no action from the sender or recipient can result in a successful delivery of the original mail because the restriction resides in the destination mail system.

 

X.3.5 Bad system configuration
The system is not configured in a manner that will permit it to accept this mail.

 

 

3.5 Network and routing status
X.4.0   Undefined network or routing or other status
Something is wrong in the network but is not clear what the actual problem is, or the problem cannot be expressed clearly with any other code.

 

X.4.1   No answer from host
The outbound connection attempt was not answered, because either the remote system is busy or was unable to accept the connection. This code useful only as a temporary error.

 

X.4.2   Bad connection
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 temporary error.

Example:
4.4.2, status=deferred (lost connection with xx.xx.xx.xx[xx.xx.xx.xx] while sending end of data — message may be sent more than once)
4.4.2, status=deferred (lost connection with xx.xx.xx.xx[xx.xx.xx.xx] while sending message body)
4.4.2, status=deferred (delivery temporarily suspended: lost connection with xx.xx.xx.xx[xx.xx.xx.xx] while sending end of data — message may be sent more than once)

This code implies that a message was being transmitted but suddenly the network connection failed. In this case both sender and destination systems must wait until a time-out and then drop the connection. The sender system will have to assume this code and queue the message for a later delivery. The destination system will just simply drop the connection.

 

X.4.3  Directory server failure
The mail system was unable to deliver this mail because there was no name resolution service available. This code is useful only with temporary errors.

Example:
4.4.3, status=deferred (Host or domain name not found. Name service error for name=domain.com type=MX: Host not found, try again)

To correct this problem the mail administrator may change the actual DNS for another one like the public 8.8.8.8 server.

 

X.4.4   Unable to route
The mail system was unable to determine the next hop because there wasn’t enough routing information in the name resolution system. This code is useful for both permanent and transient errors. An example of this situation is when the sender types a wrong domain name like “gnail” instead of “gmail”.

Example:
5.4.4, status=bounced (Host or domain name not found. Name service error for name=domain.com type=AAAA: Host not found)

This situations usually falls on the sender’s responsibility as most of the time the user typed a non-existent domain by mistake.

 

X.4.5   Mail system congestion
The mail system was unable to deliver the message because the mail system was congested.  This is useful only as a persistent transient error.

 

X.4.6   Routing loop detected
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.

 

X.4.7   Delivery time expired
The message was considered too old by the rejecting system, either because it remained on the host for 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.

Example:
BA13F20ABD: from=<user@domain.com>, status=expired, returned to sender

In this example from Postfix’s maillog the status code 5.4.7 was assumed to log this line. This code, if present, must be 5XX because the message will no longer be queued in the system.

 

 

3.6 Mail delivery protocol status
X.5.0   Undefined protocol status and others
Something was wrong with the protocol necessary to deliver the mail to next hop and the problem cannot be described using any other code.

 

X.5.1   Invalid command
A command was sent and it was out of sequence or was not supported. This code is only useful for permanent errors.

Example:
503 5.5.1 Error: send HELO/EHLO first
This problem must be resolved on the sender mail system.

 

X.5.2   Syntax error
A command was sent and it cannot be interpreted either because the syntax was wrong or because the command is not recognized. This code is only useful for permanent errors.

Example:
500 5.5.2 Error: bad syntax
502 5.5.2 Error: command not recognized
504 5.5.2 <..>: Helo command rejected: need fully-qualified hostname
504 5.5.2 <a>: Sender address rejected: need fully-qualified address
504 5.5.2 <a>: Recipient address rejected: need fully-qualified address

This problem must be resolved by the sending mail system.

 

X.5.3   Too many recipients
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.

Example:
451 4.5.3 Too many recipients specified. (in reply to RCPT TO command)

There is an implicit rule in RFC 2821 for these cases that suggests that any SMTP Server in this situation should receive the mail for the already accepted recipients. For the remaining recipients rejected by this error, the mail is still under the responsibility of the SMTP Client so the mail should be queued to retry the delivery for the remaining recipients. Because of this a receiving mail server may accept duplicated mails.

 

X.5.4  Invalid command arguments Argumentos de comando inválidos
A valid mail command was issued with invalid arguments, either because the number of arguments were out of range or represented unrecognized features. This code is only useful in permanent errors.

Example:
501 5.5.4 Syntax: MAIL FROM:<address>
501 5.5.4 Syntax: RSET
501 5.5.4 Bad message size syntax
555 5.5.4 Unsupported option: k

 

X.5.5   Wrong protocol version
A protocol version mis-match existed which could not be automatically resolved by the communicating parties.

 

 

3.7 Message content or message media status
X.6.0   Undefined media errors or others
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.

 

X.6.1   Media not supported
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.

 

X.6.2   Conversion required and prohibited
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.

 

X.6.3   Conversion required but not supported
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.

 

X.6.4   Conversion with loss performed
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.

 

X.6.5   Conversion failed
A conversion was required but was unsuccessful.  This may be useful as a permanent or persistent temporary notification.

 

 

3.8 Security or Policy status
X.7.0   Other or undefined security status
Something related to security caused the message to be rejected and the problem cannot be detailed using any other available code.

Example:
421 4.7.0 mx.server.com Error: too many errors

 

X.7.1   Delivery not authorized, message refused
The sender is not authorized to send mail to the specified destination. This may be the result of system or user defined filters. This code is useful for permanent errors.

Example:

554 5.7.1 <user@domain.com>: Relay access denied

 

X.7.2   Mailing list expansion prohibited
The sender is not authorized to send a message to the intended mailing list.  This is useful only as a permanent error.

 

X.7.3   Security conversion required but not possible

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.

 

X.7.4   Security features not supported
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.

 

X.7.5   Cryptographic failure
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.

 

X.7.6   Cryptographic algorithm not supported
A transport system otherwise authorized to validate or decrypt a message was unable to do so because the necessary algorithm was not supported.

 

X.7.7   Message integrity failure
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.

 

________________________________________________________________________

By fully understanding the principals by which the status codes are defined you may at least interpret the situation your mail server is facing by just watching at returned numbers.

For more information about the rules to create, transmit and process an email you can check out our publication on The SMTP Protocol Fundamentals.

Remember to send us your questions and comments to our Twitter account:@redinskala where you can find more information and security tips.

Thanks for your visit!

 

 

One thought on “Extended status codes (SMTP)

  1. Pingback: Códigos de status extendidos (SMTP) | RedinSkala

Comments are closed.