Rerouting and Retries

If an attempt to send a message through the chosen connector fails, the MTA tries to reroute the message. However, there are exceptions:

During rerouting, only the O/R address of the first responsible recipient is used to reroute the message. This solution is a trade-off because some messages could end up traveling a longer path than if they had been rerouted individually, but this method reduces processing time. There are no loop-detect issues because the rerouting action resets the X.400 loop-detect algorithms.

Every connector has a retry count and a retry interval that determine how many times and at what intervals the MTA tries to send a message through each of the connectors. The Site Connector and the Dynamic RAS Connector default to a 10-minute retry interval and a maximum of 144 retries. On each fan-out message copy, the MTA stores a retry count for each connector and target MTA that has been tried.

When a message is routed to an inaccessible connector, the retry count for that connector is incremented on the message, and the message is rerouted immediately using the routing and selection process outlined earlier. After all connectors have been tried and the maximum retry count has been reached, the message is marked as an NDR.

If the open connection fails for any connector, the connector starts an Open Retry timer to retry the open connection independently of the message.

After a message has been rerouted successfully, the external and internal trace information for the message is updated to indicate that the message has been rerouted.

You can prevent rerouting to the lowest-cost connector using the MTA General property page. Clear the Only use least cost routes check box.