Exchange Server Retreat (NDR) and solutions

A non-delivery report (NDR) is a system message that reports the delivery status of a message to the sender. This type of message is a subclass of a general message structure called the delivery status notification. Delivery status notifications describe three different types of situations:

• Success (ie 2.x.x Digital code)

• Persistent transient failure (ie 4.x.x Digital code)

• Permanent failure (ie 5.x.x Digital code)

For more information about delivery status notifications, refer to the Request for Comment document (RFC) 1891 and RFC 1893.

NDRs are generated whenever a message cannot be delivered. If the computer can detect the cause of the delivery failure, it maps the reason to a status code and prints the appropriate error message. (For a list of these codes, see RFC 1891 and RFC 1893.) For NDRs, most digital code is reported as "5.x.x" and is described as a permanent failure. However, there are transient conditions that can cause 4.x.x code.

It is important to note that the server reporting the problem is also listed in front of the numeric code, in the example above, for server.nwtraders.com. Sometimes the server that reports the problem is not the server that is actually experiencing the problem.

The following list describes the most commonly encountered numeric codes and their corresponding error states: • Digital code: 4.2.2

is limited to the version prior to Exchange Service Pack 3. Please refer to 5.2.2

• Digital code: 4.3.1

Possible cause: This out-of-memory error may be caused by a resource problem, such as a disk full. Alternatively, your Simple Mail Transfer Protocol (SMTP) queue is on a file allocation table (FAT) partition, and the service has reached the limit of the number of file handles that the SMTP service can open at the same time as Windows requires. You may not have a full disk error, but a low memory error.

Troubleshooting: Make sure you have sufficient disk storage space and try to run Exchange transport queues on NTFS partitions.

• Digital code: 4.3.2

First available in: Exchange Service Pack 1

Possible cause: The NDR is caused by an administrator operation that is performed through the Queue Viewer interface in Exchange System Manager.

• Digital code: 4.4.1

Possible cause: The host is not responding.

Troubleshooting: This error may be caused by a transient network state. Microsoft Exchange will automatically try to reconnect and deliver the message. If delivery still fails after multiple retries, a permanent fault NDR is generated.

• Digital code: 4.4.2

Possible cause: The connection between the servers has been disconnected.

Troubleshooting: This error message may be caused by transient network problems or server downtime. The server attempts to deliver the message within a specific time period, and then generates further status reports.

• Digital code: 4.4.6

Possible cause: exceeds the maximum number of hops for a message. This error message may also be caused by a loop between the sending and receiving servers that are not in the same organization (the message jumps and jumps until the hop count is exceeded).

Troubleshooting: This property is set for each virtual server, and you can override this setting manually (the default value is 15). Also, check to see if there are other situations that can cause loops between servers.

• Digital code: 4.4.7

Possible cause: The message in the queue has expired. The sending server tried to relay or deliver the message, but the message expired before the operation was completed. This message may also indicate that a message header limit has been reached on the remote server, or some other protocol timeout occurred during communication with the remote server.

Troubleshooting: This message usually indicates a problem on the receiving server. Verify that the recipient address is valid and that the receiving server is configured correctly to receive mail. For hosts that are receiving this error, you may need to reduce the number of recipients in the message headers. If you resend the message, the message is queued again. If the receiving server is started, the message is delivered.