Everyone is familiar with the standard SMTP email address format (user@domain.com). SMTP is a standard that allows e-mail to be exchanged between e-mail servers of different types and vendors, across the internet. What you may not know is that Exchange doesn’t use SMTP addresses to route e-mail internally. Instead, Exchange relies on an address type called X500 to route messages. When Exchange receives a message addressed to an SMTP address, one of the first things it does is lookup that address in the directory and resolve it to an X500 address. This use of X500 addresses in Exchange is important to understand as it can lead to unexpected NDRs if you are not aware of how it works.
X500 History
The use of X500 addresses in Exchange dates back to the pre-Exchange 2000 days when Exchange had its own directory. In Exchange 5.5 and previous versions, Exchange used the X400 protocol. X400 uses the Distinguished Name of an object in the LDAP directory. The problem with using a Distinguished Name is that if the object is renamed or moved in the directory tree (for example to a different server), the Distinguished Name changes and this would break mail flow as the old X400 address would no longer be valid. To get around this, Exchange relied on X500 addresses to act as aliases and hold the old X400 address. This allowed mail to be routed properly even after objects were moved or renamed.
legacyExchangeDN
Starting with Exchange 2000, Exchange was switched to using Active Directory instead of having its own directory. For backward compatibility with previous versions of Exchange, Exchange 2000 and subsequent versions of Exchange (up to 2010 as of this writing) continue to use the X500 address format for message routing. An attribute was created in Active Directory called “legacyExchangeDN” to hold an address in X500 format that Exchange 5.5 could understand. This is the “master” address on all mail-enabled objects in Exchange. Like in Exchange 5.5, it allows mail to be delivered to the proper location even if the object is moved, renamed, or even if the SMTP address is changed.
Since the legacyExchangeDN is the “master” address on all mail-enabled objects in Exchange, Outlook actually addresses internal messages using the legacyExchangeDN. You will notice that when sending internal e-mails, Outlook will resolve the object from the global address book and show the display name of the object. Behind the scenes, Outlook is actually looking up the legacyExchangeDN and using that to address the message. Even if you put the SMTP address of the object in the ”To” field, Outlook will resolve that to the legacyExchangeDN before sending. When you send an email, Outlook adds the recipients to the Outlook cache, which is used for the auto-complete as you start typing an address. The cached copy of internal recipients contains the legacyExchangeDN value as the object’s address. When you reply to any messages in your Inbox, which were sent from an internal mailbox, you are replying to the legacyExchageDN value.
How legacyExchangeDN causes NDRs
NDRs are caused by the legacyExchangeDN because a lot of administrators assume that Exchange uses SMTP for internal routing and thus assume that as they move SMTP addresses from object to object, mail delivery will work correctly. There are two common scenarios where this occurs. The first is when a mail-enabled object is deleted from Active Directory and a new object is created with the intention to take its place. An example of when this might occur is if a contact exists to route email to an external mailbox and that mailbox is now being brought into Exchange. The administrator deletes the contact, creates the new mailbox with the same display name and ensures SMTP addresses that were on the contact are added to the new mailbox. Not long after, users start complaining about receiving the following NDR:
Delivery has failed to these recipients or distribution lists:
jjmck
The recipient's e-mail address was not found in the recipient's e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.
_____
Sent by Microsoft Exchange Server 2007
Diagnostic information for administrators:
Generating server: exchange01.domain.local
IMCEAEX-_O=COMPANY_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=jjmck@domain.local
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##
The problem is that Outlook has the old object cached. When users start typing the name of the recipient, Outlook auto-completes the recipient from the cache. Since the cache contains the legacyExchangeDN of the old contact and the legacyExchangeDN of the new mailbox is different, Exchange will not be able to find the recipient and generates an NDR as a result.
The second common scenario is when you do a mail migration between organizations and you are not using migration tools that either automatically add the old legacyExchangeDN from the source mailbox to the destination mailbox as an X500 address, or rewrites the recipient addresses as SMTP during the migration of mail. A migration method where this commonly occurs is when PST exports are used to migrate mail from one organization to another. When users reply to mail migrated in this manner, it will cause an NDR as Outlook is using the legacyExchangeDN as the recipient’s address and the legacyExchangeDNs from the source organization do not exist in the target organization.
How to Prevent legacyExchangeDN NDRs
NDRs can be prevented by adding the legacyExchangeDN value of the original directory object as an X500 address on the new object. If you are planning on deleting an object and replacing it with another object, such as the example of replacing a contact with a mailbox discussed above, you would first need to get the legacyExchangeDN of the contact. You can do that by running the following Powershell command:
You would then take the value of the legacyExchangeDN and add it to the new mailbox as an X500 address. You can do this in EMC by adding a Custom address on the email addresses tab or you can run the following Powershell script:
Would translate to a legacyExchangeDN of
/o=Company/OU=Exchange Administrative Group/cn=Recipients/cn=user
You can also use MFCMAPI to open messages in Exchange mailboxes and view the PR_SENDER_EMAIL_ADDRESS property for the legacyExchangeDN value of recipients.
Once you have added the legacyExchangeDN of the old object to the new object, mail will be delivered to the new object when Outlook users reply to emails sent from the old object or use the cached object when creating new messages.
Conclusion
Hopefully this article has given you a better understanding on how Exchange routes e-mail internally and the importance the legacyExchangeDN attribute plays in message delivery. By better understanding this concept, you can plan for changes in your address book during migrations and deletion and recreation of objects. If you ensure you maintain the legacyExchangeDN value as an X500 alias when you migrate from old to new mail-enabled objects, you will ensure message delivery stays consistent and eliminate annoying NDR messages.
I'm having the same exact problem mentioned in this article, and yes after a PST migration to a new mailbox.
I've added the address of the NDR (converted) as an X500 alias as mentioned here...but the issue keeps occurring...and only from one specific user to another specific user internally. I removed the auto-complete cache and NK2 file to no avail...
I'm stuck and it's driving me crazy...this fix seems to work for everyone else. Any ideas?
Can you post the text of the NDR as well as the x500 address you added? You can change the details to hide identifying info, just make sure you change it consistently.
Comments (11)
Commented:
Thank you,
Geo
Commented:
thanks so much for sharing such a knowledge base article..you are a Champ !!
cheers !!
Commented:
I'm having the same exact problem mentioned in this article, and yes after a PST migration to a new mailbox.
I've added the address of the NDR (converted) as an X500 alias as mentioned here...but the issue keeps occurring...and only from one specific user to another specific user internally. I removed the auto-complete cache and NK2 file to no avail...
I'm stuck and it's driving me crazy...this fix seems to work for everyone else. Any ideas?
Author
Commented:-JJ
Commented:
Exchange NDR X500 issue
View More