Knowledge Base

XFOR: MTA does not Generate Requested Delivery Report

Article ID: 152928

Article Last Modified on 10/28/2006

APPLIES TO

Microsoft Exchange Server 4.0 Standard Edition
Microsoft Exchange Server 5.0 Standard Edition
Microsoft Exchange Server 5.5 Standard Edition

This article was previously published under Q152928

SYMPTOMS

You will not receive a requested Delivery Report (DR) if the message is sent through the Microsoft Exchange MS Mail Connector Interchange (MSMI) or any other gateway.

CAUSE

These messages are destined to a recipient located on a foreign messaging system. To reach the destination, the Microsoft Exchange Message Transfer Agent (MTA) must hand these messages off to either a connector, such as the MSMI or the Microsoft Exchange Internet Mail Connector (IMC), or to a 3rd party gateway developed using the Microsoft Exchange Development Kit (EDK gateway). The foreign messaging system might not have the ability to create a DR when it delivers the message to the recipient. As a result, the sender of the message will not receive a DR. This behavior is by design for messages sent from Microsoft Exchange to Microsoft Mail through the MSMI. When a message is handed off to the MSMI, the MTA cannot assume that the recipient will eventually receive the message. According to the X.400 standards, a DR must only be created when the message is delivered to a user agent (UA) or an access unit (AU).

STATUS

Microsoft does not consider the MSMI or any other gateway an AU. However, Microsoft recognizes the need for users to receive a DR, even though the foreign messaging system that the intended recipient resides in does not have the X.400 concept of a DR. Therefore, Microsoft has confirmed that this is a problem in version 4.0 of the MTA. The fix should be applied only to systems where generating a DR when the message is handed off to a gateway is absolutely necessary. A thorough understanding of the implications of applying this fix is required, see the additional information section of this article below. By applying this fix, the MTA can be configured to create a DR when the message is handed off to the MSMI or any other gateway. This problem was corrected in the latest Microsoft Exchange Service Pack. For information on obtaining the Service Pack, query on the following word in the Microsoft Knowledge Base (without the spaces):

S E R V P A C K

MORE INFORMATION

How to install this fix:

Stop the MTA Service.
For Microsoft Exchange Server version 4.0 only, save a copy of the Emsmta.exe file located in the <exchange root>\Bin directory and copy the new Emsmta.exe to that directory. This functionality is already in Microsoft Exchange Server version 5.0 and no new files are necessary.

Start Regedt32.exe and locate the registry key:

   HKEY_LOCAL_MACHINE
      \SYSTEM
         \CurrentControlSet
            \Services
               \MSExchangeMTA
                  \Parameters

Click Add Value on the Edit menu and add the following entry:

For Microsoft Exchange Server version 4.0:
```
      Entry name: DR on Gateway Transmission
      Entry type: REG_DWORD
                        
```
For Microsoft Exchange Server version 5.0:
```
      Entry name: DR for Gateway Transmission
      Entry type: REG_DWORD
                        
```
The default value (if the entry is absent) is 0. Changing the value to 1 will cause the MTA to generate a requested DR whenever a message is handed off to a foreign messaging system.
Restart the MTA Service.

NOTES:

The value is case sensitive and should be entered exactly as shown above including spaces.

This is a global setting and cannot be modified to apply only to a specific gateway. It applies to all gateways on the Microsoft Exchange Server that the fix is applied to. In this context, a gateway can be the IMC, MSMI, or any other EDK Gateway.

A requested DR will be generated by the MTA even if the connector or gateway that the message should be handed off to is not started. As soon as the MTA places the message in the queue of the connector or gateway the message is destined for, it will create the DR.

These DRs should not be used to determine that the message properly arrived at the intended destination.

1. Depending on the behavior of the foreign messaging system and the path that the message takes, it is possible that the sender could receive more than one DR.

DRs can be followed by Non Delivery Reports (NDRs) when the recipient is unknown at the foreign messaging system destination.

In the unlikely event that the message is lost on its way through any foreign messaging system, the sender might not be notified of the loss. This is dependant on the foreign messaging system's behavior.

1. DRs can be followed by Non Delivery Reports (NDRs) when the recipient is unknown at the foreign messaging system destination.

In the unlikely event that the message is lost on its way through any foreign messaging system, the sender might not be notified of the loss. This is dependant on the foreign messaging system's behavior.

1. In the unlikely event that the message is lost on its way through any foreign messaging system, the sender might not be notified of the loss. This is dependant on the foreign messaging system's behavior.

Keywords: kbprb kbusage KB152928

Microsoft KB Archive/152928

Contents