XFOR: MTA does not Generate Requested Delivery Report

 Last reviewed: August 1, 1997
Article ID: Q152928
The information in this article applies to:
  • Microsoft Exchange Server, version 4.0
  • Microsoft Exchange Server, version 5.0

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

Additional Information

How to install this fix:

  1. Stop the MTA Service.
2. 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

    4. 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.

         2. DRs can be followed by Non Delivery Reports (NDRs) when the recipient

            is unknown at the foreign messaging system destination.

         3. 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.

      

    

	    
	
    		• 
	
    

    

    






    

    

	
    


    


Additional query words:
    
Keywords          : kbbug4.00 kbfix4.00.sp3 XFOR kbusage
    
Version           : 4.0
    
Platform          : WINDOWS
    

    
    

    

    
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.  MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.  SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.

    

    

    
	
	Last reviewed:  August 1, 1997
	
    
	© 1998 Microsoft Corporation. All rights reserved. Terms of Use.