Delivery Status Notification

A Delivery Status Notification (DSN) is the message returned by a mail server after accepting or rejecting incoming E-Mail. Rejected messages are also referred to as bounces.

A typical failure notification or bounce could look like this:

554 5.7.1 <user@domain.tld>: Recipient address rejected: Access denied

A typical success notification could look like this:

250 2.0.0 Requested mail action okay, completed: id=1a2B3c4D-6F7g8H9i1J-00A1BC

We see 3 things:

• Basic status codes, for example 554 and 250.
• Extended status codes, for example 5.7.1 and 2.0.0.
• Plus a bunch of text, with a humanly readable desription of events.

Status types and definitions

The below text is quoted from Wikipedia:

Basic status codes

A "Basic Status Code" SMTP reply consists of a three digit number (transmitted as three numeric characters) followed by some text. The number is for use by automata (e.g., email clients) to determine what state to enter next; the text ("Text Part") is for the human user.

The first digit denotes whether the response is good, bad, or incomplete:

• 2yz (Positive Completion Reply): The requested action has been successfully completed.
• 3yz (Positive Intermediate Reply): The command has been accepted, but the requested action is being held in abeyance, pending receipt of further information.
• 4yz (Transient Negative Completion Reply): The command was not accepted, and the requested action did not occur. However, the error condition is temporary, and the action may be requested again.
• 5yz (Permanent Negative Completion Reply): The command was not accepted and the requested action did not occur. The SMTP client SHOULD NOT repeat the exact request (in the same sequence).

The second digit encodes responses in specific categories:

• x0z (Syntax): These replies refer to syntax errors, syntactically correct commands that do not fit any functional category, and unimplemented or superfluous commands.
• x1z (Information): These are replies to requests for information.
• x2z (Connections): These are replies referring to the transmission channel.
• x3z : Unspecified.
• x4z : Unspecified.
• x5z (Mail system): These replies indicate the status of the receiver mail system.

Enhanced status codes

The Basic Status Codes have been in SMTP from the beginning, with RFC821 in 1982, but were extended rather extensively, and haphazardly so that by 2003 RFC3463 rather grumpily noted that: "SMTP suffers some scars from history, most notably the unfortunate damage to the reply code extension mechanism by uncontrolled use."

RFC3463 defines a separate series of enhanced mail system status codes which is intended to be better structured, consisting of three numerical fields separated by ".", as follows:

class "." subject "." detail

  class   = "2" / "4" / "5"

  subject = 1 to 3 digits

  detail  = 1 to 3 digits
  

The below text is quoted from the IANA SMTP Enhanced Status Codes Registry:

The classes are defined as follows:

Code	Summary	Description	Reference
2.XXX.YYY	Success	Success specifies that the DSN is reporting a positive delivery action. Detail sub-codes may provide notification of transformations required for delivery.	RFC3463 (Standards track)
4.XXX.YYY	Persistent Transient Failure	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. In this case, the bounce will be classified as a soft-bounce.	RFC3463 (Standards track)
5.XXX.YYY	Permanent Failure	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.	RFC3463 (Standards track)

For an extensive list on Class Sub-Codes, visit IANA or look at RFC3463.

Types of bounces

Bounces are DSN's with a status code either starting with 4 (transient/temporary) or 5 (permanent). If a bounce is received, one of the following actions can be taken:

1. to stop sending to the bouncing address immediately.
2. to try a few more times and stop sending if it continuously doesn't work.
3. to keep on sending to the address in question, despite the bounce.

It's unfortunate to have only two types status codes, when there are three types of actions possible. This way, we can't pick the desired action merely based on the status code.

Hardbounces (5XX)

Hardbounces are always permanent bounces, but not all permanent bounces are hardbounces. The classic example of a hardbounce, is a non-existing mailbox. Hardbounces should never be retried. Once a hardbounce is received, the address in question is never to be sent to again. Non existing mailboxes can be transformed to recycled spamtraps. Therefore it's important regularly send to your active list and never send to previously hardbounced contacts.

Softbounces (4XX)

Softbounces are always temporary bounces, but not all temporary bounces are softbounces. Classic examples of softbounces are a full mailbox, or a network timeout. Softbounces should be retried, but not forever. A rule of fist is to stop sending after a maximum of 4 softbounces from the same recipient.

But what about "Blockbounces"?

The third scenario, is where a message is blocked due to policy reasons. In this case, the reason for the block should be mitigated and sending should continue. Sender reputation isn't negotiated when no sending is taking place. Therefore it's important never to stop sending to blockbounced addresses. Blockbounces can be either permanent (5XX) or transient (4XX).

Bounce processing

The big question that remains is how to process three bounce types when only two status types are bounces? The only way to do this, is by using regular expressions on the humanly readable text in the DSN. For example, any message where the DSN text contains words such as "spam", "policy" or "blocked" can be safely regarded blockbounces. Commonly, classification of bounces is done in the following order:

1. Try to find a classification based on regex.
2. If no classsification can be determined, it's either a hardbounce (5XX) or a softbounce (4XX).

Useful links

• Bounce Message
• List of SMTP server return codes
• IANA SMTP Enhanced Status Codes Registry
• RFC3463