E-mail is normally fairly resilient, but sometimes things do happen that prevent e-mail messages from being delivered as expected. This is especially true when an Exchange Server is attempting to deliver e-mail messages to external addresses. You just never know when a router somewhere along the way is going to be down, or when the recipient may be having trouble with their mail server. These and a number of other factors can prevent messages from being delivered as expected. In this article, I will explain how you can configure Exchange Server 2007 to react appropriately when it is not able to deliver a message to an external recipient.
When Exchange Server has trouble delivering a message to the outside world, the first thing that it does is to attempt to determine if the problem is related to a connection failure, or if the outbound messages been rejected by the recipient. Exchange is able to accomplish this by using some code that are built into the SMTP protocol.
Delivering an e-mail message involves issuing a series of SMTP commands to the recipient’s mail server, and then waiting for the response code after each command. To see what some of the more common response codes look like, click here.
Anytime that a message ends up not being deliverable, Exchange server looks for SMTP response codes in an effort to determine the reason for the delivery failure. The response code will tell Exchange if the recipient rejected the message, and why. Sometimes though, a message may fail to be delivered because of a connection problem. When this happens, Exchange Server will repeatedly retried to deliver the message in hopes that the connection will eventually become available. Eventually though, Exchange Server will decide that enough is enough, and declare the message as being undeliverable. Typically when this happens Exchange will send a non-delivery report to the user who sent the message.
What I have described so far is the default behavior for Exchange Server 2007. You do however, have the option of modifying the behavior. You can actually control the number of times that Exchange Server reattempts to deliver a message that was previously undeliverable.
As I’m sure you probably know, message delivery occurs at the Hub Transport Server level. Therefore, you can configure Message limits by opening the Exchange Management Console, and the navigating through the console tree to Server Configuration | Hub Transport. Now, click on your Hub Transport server, and then click on the properties link. When you do, the console will display the properties sheet for the hub transport server. You can find the message delivery options located on the Limits tab that is shown in Figure A.
Figure A The Limits tab allows you to configure Message retries.
The first setting found on this tab is the Outbound Connection Failure Retry Interval. As the name implies, this setting controls how often Exchange Server attempts to establish a connection when a connection failure has been detected. The default setting is 10 minutes, and Microsoft advises you not change this limit unless you are instructed to do so by Microsoft’s technical support staff.
Just beneath that, you can see from settings that allow you to specify the transient failure retry interval, and the transient failure retry attempts. Essentially this is telling Exchange server to try to deliver the message six more times, and to wait five minutes (300 seconds) between each attempt. It is perfectly permissible to modify the settings, and any other settings that I’m going to be talking about.
The next thing that you will encounter is the Maximum Time Since Submission setting. This setting allows you to specify the number of days the message will remain in queue before it is considered to be undeliverable. When a message is declared to be undeliverable, the message is deleted from the queue and the sender is sent a nondelivery report.
The final two settings on the Limits tab allow you to control the maximum number of concurrent outbound connections, and the maximum number of concurrent outbound connections per domain. Although I have not seen any Microsoft documentation recommending that you not change these settings, I would strongly recommend keeping the default settings.
Remember, you can’t prevent message delivery failures from happening, but you can control how Exchange Server reacts to these delivery failures. In this article you saw, step by step, how to configure Exchange Server 2007 to react appropriately when it is not able to deliver a message to an external recipient.
Got a question? Post it on our Exchange Server Forums!