Users receiving NDR for other non-existent users

Hi community,

The following issue applies to an Exchange 2010 SP3 environment running RU 8-v2.

Some users have recently started reporting an issue where they are receiving an NDR for another user who no longer exists in our organization (mailbox and account have been deleted). Here is an example scenario:

Email from: communications@external.com
Email to: Various user mailboxes (user1@company.com, user2@company.com...)
ReturnPath: communications@external.com

The first point I'd like to make is none of the recipients are distribution lists, they are all individual mailboxes (I point this out because of a similar issue I read regarding distribution list SPF compliance - http://exchangeserverpro.com/exchange-server-ndr-loop-distribution-list/). In my examples to come, user2@company.com no longer exists in our organization.

The email is processed by Exchange and broken up into several different MessageIDs - this is my second point because when the problem occurs, if one MessageID contains only user1@company.com & user2@company.com (who no longer exists) the NDR will definitely go to user1@company.com... If there are others it appears to be random selection from the active users in that same MessageID.

In Exchange Message Tracking, we'll then see for user2@company.com:
FAIL - ROUTING
550 5.1.1 RESOLVER.ADR.RecipNotFound; not found
ReturnPath: user1@company.com

user1@company.com then receives the NDR for user2@company.com complete with message headers, and of particular note:
user2@company.com
#< #5.1.1 smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found> #SMTP#
Resent-From: <user1@company.com>
Return-Path: communications@external.com
X-MS-Exchange-Inbox-Rules-Loop: user1@company.com

Afterwards, user1@company.com had all of their inbox rules, delegates etc completely cleared but this did not solve the problem. I have described the problem above, now here is some additional information that I feel might be useful...

The users who have so far reported this issue have one commonality - they were part of an email migration to another Exchange organization within our company, and we actually forward all email for user1@company.com to their new home using the ForwardingSMTPAddress attribute.

So, if we go back to that same MessageID and look in Exchange Message Tracking we'll also see:
DEFER - AGENT - Redirection Agent
250 2.0.0 Recipient address expanded by Redirection Agent
ReturnPath: user1@company.com

It's normal behaviour because we're forwarding mail, but I am wondering if this "rewriting" the ReturnPath for the non-existent user as well. Help!
PHN-sodriscollAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

suriyaehnopCommented:
0
PHN-sodriscollAuthor Commented:
Hi suriyaehnop,

Thanks for posting and for the suggestion. Following the instructions in your link, I looked at two affected users, but neither had an entry for Schedule+ EMS Interface or anything similar to free/busy in their rules table.
0
suriyaehnopCommented:
Have you try to move the user to another mailbox database?
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

PHN-sodriscollAuthor Commented:
We moved two of the affected users to a different mailbox database last night, but unfortunately, the problem is still occurring.
0
PHN-sodriscollAuthor Commented:
I've requested that this question be closed as follows:

Accepted answer: 0 points for PHN-sodriscoll's comment #a40807022

for the following reason:

Discovered when attempting to re-produce in Development environment. If you'd like to re-produce yourself in Exchange (example):

Hub Transport > Remote Domains > Default *
Uncheck "Allow non-delivery reports"

From an external address, send an email to a user address that exists in your organization and to a non-existent address. Observe in Message Tracking the ReturnPath for non-existent address will be the address of the user that does exist.
0
PHN-sodriscollAuthor Commented:
To my embarrassment, I have since realized this is the wrong solution. In testing it more in Dev, I discovered not all of the steps to reproduce were included.
0
PHN-sodriscollAuthor Commented:
I have discovered in Dev that using the ForwardingSMTPAddress is definitely at the heart of the matter. Easily reproducible in Dev:

Set-Mailbox user1@company.com -ForwardingSMTPAddress user1@newcompany.com

Send email from any address external to the organization to user1@company.com and user2@company.com. user1@company.com will become the ReturnPath for user2@company.com.

I have submitted a Microsoft case for further investigation.
0
PHN-sodriscollAuthor Commented:
A final update on this matter for anybody who might come across this post, and again my apologies for any confusion caused by what I originally thought was the solution.

I worked through a Microsoft case and it was basically determined by Microsoft that the system is working as intended and is compliant with SPF standards. Their explanation is that since company.com is not authoritative (or part of the SPF record) for the external sender domain, when I forward to another domain (newcompany.com) that I am also not authoritative for, I could potentially be spoofing the external sender domain so Exchange will re-write the ReturnPath to someone@company.com.

Drill down further, and this will only occur if the Exchange role or hygiene layer which is producing the NDR has visibility into the forwarding rule (i.e. if this is happening at the Mailbox Server). This means if you reject the message at a transport layer, this issue won't occur.

One possible solution using Exchange native tools is to use the Anti-spam transport agents - which ships with the Edge Transport role but can also be installed on the Hub Transport role. Once installed you would enable 'Recipient Filtering' and in the properties under the 'Blocked Recipients' tab select 'Block messages sent to recipients that do not exist in the directory.'

 We have not yet decided on an approach as an organization, but consider the root cause identified and this issue closed.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
PHN-sodriscollAuthor Commented:
Completed Microsoft case to determine behaviour is as designed.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.