KnowledgeBase Archive

An Archive of Early Microsoft KnowledgeBase Articles

View on GitHub

Q152928: XFOR: MTA does not Generate Requested Delivery Report

Article: Q152928
Product(s): Microsoft Exchange
Version(s): winnt:4.0,5.0,5.5
Operating System(s): 
Keyword(s): kbusage exc4 exc5 exc55
Last Modified: 19-DEC-1999

-------------------------------------------------------------------------------
The information in this article applies to:

- Microsoft Exchange Server, versions 4.0, 5.0, 5.5 
-------------------------------------------------------------------------------

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:

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.

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

5. 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          : kbusage exc4 exc5 exc55 
Technology        : kbExchangeSearch kbExchange500 kbExchange550 kbExchange400 kbZNotKeyword2
Version           : winnt:4.0,5.0,5.5
Issue type        : kbprb

=============================================================================

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.

Copyright Microsoft Corporation 1986-2002.