Delivery status notifications in Exchange Server and in Small Business Server2009-01-15 at 06:32 am databasemind
Delivery status notifications in Exchange Server and in Small Business Server.
This article is absolute reference to http://support.microsoft.com/kb/284204
- Success (2.X.X numeric codes)
- Persistent transient failure (4.X.X numeric codes)
- Permanent failures (5.X.X numeric codes)
To learn more about delivery status notifications, see Request for Comment (RFC) 1891 and RFC 1893.
NDRs are generated whenever a message cannot be delivered. If the computer can detect the reason for the failed delivery, it maps the reason onto a status code, and a corresponding error message is printed. (To see a list of these codes, see RFC 1891 and RFC 1893.) For NDRs, most numeric codes are reported in the form of 5.X.X and are described as permanent failures. However, there are certain transient conditions that cause 4.X.X codes.
Note that the server that is reporting the problem is listed before the numeric code. In the example NDR in the “Introduction” section, the reporting server is server.nwtraders.com. Sometimes the server that is reporting the problem is not the server that is actually experiencing the issue.
The following list describes the numeric codes and the corresponding error conditions that most frequently occur:
- Numeric Code: 4.2.2Only available in Exchange 2000 Service Pack 2 or earlier. See 5.2.2
- Numeric Code: 4.3.1Possible Cause: This code may be caused by resource problem such as a disk full condition. This code may also occur if your Simple Mail Transfer Protocol (SMTP) queue is on a File Allocation Table (FAT) partition and the service has reached a Windows-imposed limit on the number of concurrent file handles that can be opened by the SMTP Service. In this case, instead of receiving a disk full error, you might be receiving an out of memory error.Troubleshooting: Make sure you have sufficient disk storage, and try to operate your Exchange Transport queues on an NTFS partition.
- Numeric Code: 4.3.2First Available: Exchange 2000 Service Pack 1Possible Cause: The message was not delivered because of Administrator action through the queue viewer interface in Exchange System Manager.
- Numeric Code: 4.4.1Possible Cause: The host is not responding.Troubleshooting: This code may be caused by transient network conditions. Exchange will automatically try again to connect and deliver the e-mail. If delivery still fails after multiple tries, a permanent failure NDR will be generated.
- Numeric Code: 4.4.2Possible Cause: The connection has been dropped between servers.Troubleshooting: This code may be caused by transient network issues or servers that are down. The server tries to deliver the message for a specific time period, and then generates additional status reports.
- Numeric Code: 4.4.6Possible Cause: The max hop count was exceeded for the message. This code may also occur if a loop situation exists between a sending server and a receiving server that are not in the same organization. In this scenario, the message bounces back and forth until the hop count is exceeded.Troubleshooting: The max hop count property is set for each virtual server, and you can manually override this setting (the default setting is 15 for Exchange 2000 Server and 30 for Exchange Server 2003). Additionally, look for any situations that could cause loops between servers.
- Numeric Code: 4.4.7Possible Cause: The message in the queue has expired. The sending server tried to relay or deliver the message, but the action was not completed before the message expiration time occurred. This NDR may also indicate that a message header limit has been reached on a remote server or that some other protocol timeout occurred during communication with the remote server.
Troubleshooting: This code typically indicates an issue on the receiving server. Verify the validity of the recipient address, and verify that the receiving server is configured to receive messages correctly. You may have to reduce the number of recipients in the header of the message for the host that you are receiving this NDR from. If you resend the message, it is placed in the queue again. If the receiving server is on line, the message is delivered.
- Numeric Code: 4.4.9First Available: Exchange Server 2003Possible Causes: This code indicates that a temporary routing error occurred or that a bad routing configuration exists. This issue may occur in one or both of the following scenarios:
- A Simple Mail Transfer Protocol (SMTP) connector is configured to use DNS without a smart host and is also configured to use a non-SMTP address space such as an X.400 address space.
- A message was sent to a recipient who was identified as a member of a routing group that was deleted.
Troubleshooting: If the problem persists, use the WinRoute tool to examine the routing groups in the tree view pane, and then examine the address spaces of the route that the problem message takes. For more information about the WinRoute tool, click the following article number to view the article in the Microsoft Knowledge Base:281382 (http://support.microsoft.com/kb/281382/ ) How to use the WinRoute tool
- Numeric Code: 4.6.5First Available: Exchange Server 2003Possible Causes: This code occurs when conversion of an inbound SMTP failed because the code page that is specified in the message is not installed on the receiving server. This delivery status notification contains only the original message headers. None of the original content is provided.
Troubleshooting: View the MIME of the original message. Make sure that the required language files are installed on the server that is receiving the message.
- Numeric Code: 5.0.0First Available: All numeric codes that were first available with Exchange 2000 Service Pack 1 (4.3.2, 5.4.0, 5.4.4, and 5.5.0) were classified as 5.0.0 in Exchange 2000 Service Pack 1 and earlier.Possible Causes:
- There is no route for the specified address space. For example, an SMTP connector is configured, but this address does not match.
- DNS returned an authoritative host that was not found for the domain.
- The routing group does not have a connector defined. Mail from one server in one routing group does not have a route to another routing group.
- An SMTP protocol error occurred.
- Correct the address space, or add an address space of type SMTP with asterisk (*) value to one or more SMTP connectors.
- Verify that DNS is working correctly.
- Make sure that the routing groups have connectors that connect them.
- If you are running Exchange 2000 without Service Pack 1, apply Service Pack 1 to help determine the actual issue.
- Numeric Code: 5.1.0Possible Cause: This code indicates a general categorizer-based failure (bad address failure). An e-mail address or other attribute could not be found in the directory. This issue may occur if contact entries do not have the targetAddress attribute set. This issue occurs most frequently when MDAccess receives “object not found” errors from DSAccess when the Categorizer is doing the homeMDB lookup on a user.This issue also occurs if you used Microsoft Outlook to save your e-mail message as a file and someone opens and replies to this message offline. The message property only preserves the legacyExchangeDN when Outlook delivers the message. Therefore, the homeMDB lookup may fail.
Troubleshooting: Verify the recipient address and resend the message. Verify that the recipient address is formatted correctly and that the categorizer was able to correctly resolve the recipient.
- Numeric Code: 5.1.1Possible Cause:
- The e-mail account does not exist at the organization the message was sent to. This issue may occur if there was a problem when users were moved between sites. For example, if a former Administrative_Group_1 user moves to Administrative_Group_2 and then replies to an old e-mail message, or if the user does not re-create his or her Outlook profile, an old Administrative Group style LegDN address will be used, and an NDR is generated.
- The message was sent to obsolete personal address book entries.
- The categorizer rejected delivery because you configured your SMTP contact with see comment SMTP RFC821 characters.
Troubleshooting: Use the troubleshooting procedure described for numeric code 5.1.0.
- Numeric Code: 5.1.3Possible Cause: Bad address syntax. For example, a contact is configured with a targetAddress attribute that has no address type.Troubleshooting: Use the troubleshooting procedure described for numeric code 5.1.0.
- Numeric Code: 5.1.4Possible Cause: Two objects have the same proxy address, and mail is sent to that address. This issue may also occur if the recipient does not exist on the remote server.Troubleshooting: Verify the recipient address and resend the message.
- Numeric Code: 5.1.6First Available: Exchange 2000 Service Pack 2Possible Cause: The user directory attributes, such as homeMDB or msExchHomeServerName, may be missing or corrupted.
Troubleshooting: Verify the integrity of the user directory attributes, and then run the Recipient Update Service again to make sure that the attributes that are required for transport are valid.
- Numeric Code: 5.1.7First Available: Exchange 2000 Service Pack 2Possible Cause: The sender has a malformed or missing mail attribute in the directory structure. The Transport categorizer cannot deliver the mail item without a valid mail attribute.
Troubleshooting: Verify the sender directory structure and determine whether the mail attribute exists.
- Numeric Code: 5.2.1Possible Cause: Local mail is refused because the message is too big. An absent Master Account Security ID number (SID) on the recipient can also cause this error message.Troubleshooting: Verify access permissions in addition to the message size. Determine if the recipient has an SID.
- Numeric Code: 5.2.2First Available: Exchange 2000 Service Pack 3 (previously 4.2.2 in earlier release).Possible Causes: The recipient’s mailbox is over its storage limit.
Troubleshooting: Verify the mailbox storage and the queue storage quota limit.
- Numeric Code: 5.2.3Possible Cause: The message is too large for the local quota. For example, a remote Exchange user may have delivery restrictions set with max incoming message size.Troubleshooting: Resend the message without attachments, or set the server side limit or the client side limit to permit a larger message size.
- Numeric Code: 5.3.0First Available: Exchange Server 2003Possible Causes: Exchange Server 2003 has a feature that permits Exchange 2003 to operate without the Message Transfer Agent (MTA). If a message was sent incorrectly by using the MTA route, this delivery status notification is returned to the sender.
Note Although Exchange 2003 can operate without the MTA, Microsoft does not recommend or support this configuration.
To turn on this feature and to prevent the messages from queuing to the MTA, follow these steps:
- Disable the MTA service.
- Set the DWORD value to 0 in the following registry subkeys for every information store database and public folder store:
HKLM\System\CurrentControlSet\Services\MsExchangeIS\<Server Name>\<PrivMDB_GUID>\Gateway In Threads
HKLM\System\CurrentControlSet\Services\MsExchangeIS\<Server Name>\<PrivMDB_GUID>\Gateway Out Threads
When you do this, you are making store resources that are associated with MTA delivery available.
Troubleshooting: Check your routing topology. Use the WinRoute tool to make sure that the routes are correctly replicated between servers and routing groups.
Make sure that if there are multiple virtual servers, that none are set to All Unassigned.
- An authoritative host was not found in DNS.
- The smarthost entry is incorrect.
- FQDN name in HOSTS file. This issue was fixed in Windows 2000 Service Pack 3 (SP3).
- There was a DNS failure or you constructed an invalid IP address for your smarthost. *
- SMTP VS does not have a valid FQDN, or your SMTP VS FQDN lookup failed.
- A contact’s SMTP domain does not resolve to any SMTP address spaces.
Troubleshooting: Use Nslookup to check the DNS. Verify that the IP address is in IPv4 literal format. Verify that there is a valid DNS entry for the server or computer name in question. If you are relying on the FQDN in HOSTS file, ignore it and update the entry in Exchange System Manager with valid IP address or correct name.
Troubleshooting: Add or configure your Routing Group Connector between Routing Groups.
The targetAddress attribute is set on a mailbox-enabled user. Hosting Pack: This is a common hosting configuration problem when someone creates a contact in organizational unit (OU) 1 and then creates a user in OU 2 that has the same e-mail address by using the user provisioning tool.Troubleshooting:
- This issue occurs when contactA has an alternate recipient that points to contactB and contactB has an alternate recipient that points back to contactA. Check the alternative recipient for every contact.
- Check and remove the targetAddress attribute from mailbox-enabled users.
- For hosting where you want to send mail from one user in one company (OU) to another company (OU), it is best to configure the following two related objects:
User: SMTP proxy: email@example.com
Contact: targetAddress: firstname.lastname@example.org; SMTP proxy: email@example.com
Troubleshooting: If this issue occurs because of a domain that matches the FQDN of an Exchange server in the recipient policy, you must remove that entry.
Troubleshooting: Run an SMTP Log or a Network Monitor trace to see why the remote SMTP server rejects the protocol request.
Note The default recipient limit on a Simple Mail Transfer Protocol (SMTP) message is 5000. To set this limit, start the Exchange System Manager, click the Global Settings node, right-click Message Delivery, and then click Properties. This can also be a per-user setting in the Active Directory.
- The message contains more than 250 attachments. More than 250 attachments cause the MAPI_E_TOO_BIG error.
- Mail has been sent with a malformed addr822 header.
- Reduce the number of attachments in the message, and then resend the message.
- Correct the header. The error is misleading, as it indicates the NDR occurs because of the malformed P2 headers.
- General access denied, sender access denied – the sender of the message does not have the privileges required to complete delivery.
- You are trying to relay your mail through another SMTP server and it does not permit you to relay.
- The recipient might have mailbox delivery restrictions enabled. For example, a recipient’s mailbox delivery restriction was set to receive from a Distribution List only and non-members’ email will be rejected with this error.
- For Exchange Server 2003, a distribution list can be configured to restrict mail delivery from unauthenticated users. Mail that is sent by using an unauthenticated SMTP session are rejected.
Troubleshooting: Check system privileges and attributes for the contact and retry the message. Also, make sure you are running Exchange 2000 Service Pack 1 or later for other potential known issues.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
Leave a Reply
You must be logged in to post a comment.