|
|
| (2 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| 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'''.
| | #REDIRECT [[Delivery_Status_Notification_(DSN)]] |
| | |
| A typical '''failure notification''' or '''bounce''' could look like this:
| |
| | |
| <pre>
| |
| 554 5.7.1 <user@domain.tld>: Recipient address rejected: Access denied
| |
| </pre>
| |
| | |
| A typical '''success notification''' could look like this:
| |
| | |
| <pre>
| |
| 250 2.0.0 Requested mail action okay, completed: id=1a2B3c4D-6F7g8H9i1J-00A1BC
| |
| </pre>
| |
| | |
| We see 3 things:
| |
| | |
| * Basic status codes, for example 554 and 250.
| |
| * Enhanced status codes, for example 5.7.1 and 2.0.0.
| |
| * Plus a bunch of text, with a humanly readable description of events.
| |
| | |
| | |
| =Status types and definitions=
| |
| ''The below text is quoted from [[wikipedia:List_of_SMTP_server_return_codes|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 [http://www.rfc-editor.org/rfc/rfc821.txt RFC821] in 1982, but were extended rather extensively, and haphazardly so that by 2003 [http://www.rfc-editor.org/rfc/rfc3463.txt 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.''"
| |
| | |
| [http://www.rfc-editor.org/rfc/rfc3463.txt 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 [https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml IANA SMTP Enhanced Status Codes Registry]'':
| |
| | |
| The '''classes''' are defined as follows:
| |
| | |
| {| class="wikitable"
| |
| |-
| |
| ! 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.
| |
| | [http://tools.ietf.org/html/rfc3463 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.
| |
| | [http://tools.ietf.org/html/rfc3463 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.
| |
| | [http://tools.ietf.org/html/rfc3463 RFC3463 (Standards track)]
| |
| |}
| |
| | |
| For an extensive list on Class Sub-Codes, visit [https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml IANA] or look at [http://www.rfc-editor.org/rfc/rfc3463.txt 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:
| |
| | |
| # to stop sending to the bouncing address immediately. | |
| # to try a few more times and stop sending if it continuously doesn't work.
| |
| # 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:
| |
| | |
| # Try to find a classification based on regex.
| |
| # If no classsification can be determined, it's either a hardbounce (5XX) or a softbounce (4XX).
| |
| | |
| =Useful links=
| |
| | |
| * [[wikipedia:Bounce_message|Bounce Message]]
| |
| * [[wikipedia:List_of_SMTP_server_return_codes|List of SMTP server return codes]]
| |
| * [https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml IANA SMTP Enhanced Status Codes Registry]
| |
| * [http://www.rfc-editor.org/rfc/rfc3463.txt RFC3463]
| |