DOCUMENT:Q178436 21-MAR-1999 [exchange] TITLE :XFOR: Looping Messages over Internet Mail Service Site Connector PRODUCT :Microsoft Exchange PROD/VER:WinNT:5.0,5.5 OPER/SYS: KEYWORDS:kbusage ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Exchange Server, versions 5.0, 5.5 ------------------------------------------------------------------------------- SYMPTOMS ======== A looping message may result if you send a message with delivery receipt notification when using the Internet Mail Service as a site connector. The condition that causes this is when the users have multiple proxy addresses and the Internet Mail Service server receiving the SMTP mail uses the incorrect proxy address to forward across the site connector. The messages can be observed looping between the two Internet Mail Service servers, or between the Internet Mail Service and a forwarding SMTP host. Because the message is looping, the sender who requested delivery receipt notification does not receive it. Symptoms that accompany this problem are slowdown of the Internet Mail Service and increased use of disk space when Internet Mail Service logging or Message Archival is enabled. CAUSE ===== When the Internet Mail Service receives a message with delivery receipt notification enabled, it does not use the correct P1 address when it creates the delivery receipt message. Because the P1 in the message is incorrect, the message is directed to the wrong place. This problem does not occur with a regular SMTP message. This only happens when the Internet Mail Service creates a delivery receipt message. Note also that the delivery receipt message is a newly created message. When the Internet Mail Service creates a new message, it does not add additional "Received:" headers to the original delivery receipt. STATUS ====== Microsoft has confirmed this to be a problem in Microsoft Exchange Server, version 5.0. A supported fix is now available, but has not been fully regression-tested and should be applied only to systems experiencing this specific problem. Unless you are severely impacted by this specific problem, Microsoft recommends that you wait for the next Service Pack that contains this fix. Contact Microsoft Technical Support for more information. This fix has been posted to the following Internet location: ftp://ftp.microsoft.com/bussys/exchange/exchange-public/fixes/Eng/Exchg5.0/Post-SP2-IMS/ Microsoft has confirmed this to be a problem in Microsoft Exchange Server version 5.5. This problem has been corrected in the latest U.S. Service Pack for Microsoft Exchange Server version 5.5. 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 ================ This error occurs in a specific configuration. To reproduce it, set up two Internet Mail Service servers, using Domain Name Service (DNS) to resolve addresses. One Internet Mail Service server (IMC1) is configured in DNS to receive all SMTP mail destined for Exchange users. Local users have SMTP proxy addresses such as: user1@company.com DNS entries for IMC1 would look like: imc1.company.com IN A 120.120.120.120 ; This is a sample IP ; address. company.com IN MX 10 imc1.company.com ; All mail addressed to ; user@company.com will go ; to IMC1. The second Internet Mail Service server (IMC2) is configured as a site connector to the first. Directory replication successfully completes between the servers. Local users have two SMTP proxy addresses: user2@company.com ; marked as the REPLY address, that is, this is ; what is placed in the from field. user2@imc2.company.com DNS entries for IMC2 would look like: imc2.company.com IN A 121.121.121.121 ; This is a sample IP ; address. imc2.company.com IN MX 10 imc2.company.com ; All mail addressed to ; user@imc2.company.com ; will go to IMC2. User2 on IMC2 sends a message to user1 on IMC1, with a delivery receipt requested. The message reaches user1 correctly. When a delivery receipt is generated by IMC1, the P1 recipient is user2@company.com (that is, RCPT TO: user2@company.com), and P1 sender is null (that is, MAIL FROM: <>). The message is sent; the relay host adds its "Received:" headers and sends it back to IMC1. IMC1 looks in the global address list (GAL), checks the flags set on the P1 recipient address, perceives it cannot encapsulate it, and sends it to IMC2. The Internet Mail Service also does not use the second SMTP proxy for user2 (user2@imc2.company.com). Instead, it finds and uses user2@company.com, because it is the primary SMTP proxy. A new message to user2@company.com from a null From field is now sent. The relay host receives it, adds its "Received:" headers, and sends it back to IMC1. This cycle continues. Additional query words: IMC encap encapsulation ====================================================================== Keywords : kbusage Technology : kbExchangeSearch kbExchange500 kbExchange550 kbZNotKeyword2 Version : WinNT:5.0,5.5 Hardware : ALPHA PPC x86 Issue type : kbbug Solution Type : kbfix ============================================================================= 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 1999.