Q178436: XFOR: Looping Messages over Internet Mail Service Site Connector
Article: Q178436
Product(s): Microsoft Exchange
Version(s): WinNT:5.0,5.5
Operating System(s):
Keyword(s): kbusage
Last Modified: 21-MAR-1999
-------------------------------------------------------------------------------
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 1986-2002.