You will find a lot of posts related to this issue. I read a bunch of them on internet too. What interested me more is a cause behind this problem. Although this problem is very generic and doesn’t occur in every organization after upgrading to Exchange 2010 there are many people I see who reported the same problem in various forums. In all cases I saw on internet, users on a specific store experienced this problem.
Typical symptoms are:
A user with mailbox on an Exchange 2010 store sends an email to another user with mailbox on Exchange 2003 store and receives an unexpected NDR even though the recipient user account exists and the message is well within configured size limits.
Delivery has failed to these recipients or groups:
There’s a problem with the recipient’s mailbox. Please try resending this message. If the problem continues, please contact your helpdesk.
Diagnostic information for administrators:
Generating server: exchange2003.exchange.local
#< #5.2.1> #SMTP#
You also see the application log full of Event IDs 9666, 9667
Microsoft Exchange SMTP 5.2.1 is generated when the message is too big or the recipient is missing SID on it. This can not be a cause for sure because the same recipient can receive other emails without any problem. So, I decided to drill down a little more and figure out what happens when these NDRs are generated by Exchange 2003.
Event IDs 9666 and 9667 are logged to indicate that the exceeded named properties quota in a particular information store database. Above mentioned NDR is very closely related to the event IDs 9666 and 9667. Microsoft Exchange team has a very good post on their blog explaining the named properties (so called named props). I strongly recommend you reading it first here –> Confused About Named Properties Quotas in Exchange 2003 and Exchange 2007? Join the Club!
So, here is what happens when an email sent from Exchange 2010 to a recipient on an Exchange 2003 information store:
According the post linked above, Microsoft Exchange Server 2003 allows 16,384 named props creation for authenticated users by default however, insertion of new named props is stopped once the rows in the table exceed the number 16,384 for authenticated users and 8,192 for non-authenticated users. Unless the row limit is hit the server will continue accepting creation of new named props in the named props table. These named props are typically created by an application that connects to the exchange information store using MAPI. This can be an enterprise application which can read/write into database using MAPI connection or an outlook plug-in which uses exchange information store database for reading or writing information in mailbox. Also, custom properties/headers attached to the emails coming from internet are also inserted into the named props table. For example: if you have a spam filtering mechanism that stamps an additional header called x-spamScore-linux in the inbound message, this header is automatically added in named props table by Microsoft Exchange information store service. This is definitely required to display the message and its properties in outlook correctly. This behavior causes the named properties table to fill with new named properties.
Coming back to the original topic of NDRs: for an instance just imagine a scenario where you exchange 2003 store database named props quota has reached and there is no room in the table to add new named props and a user from Exchange 2010 using outlook 2010 sends an email to another user on the exchange 2003 store. As described earlier named props table reached to the maximum limit will not be able to add new named props attached with the message coming from Exchange 2010 server and hence store will generate an intermittent NDR.
Are you saying this happens to every message sent from Exchange 2010? Answer is NO. It does not happen to every message. This would happen only if the message contains additional named properties attached to it which are absent in the Exchange 2003 information store named props table and need insertion in the table. In most of the cases a plain text email sent using Outlook would get delivered but an HTML email or a meeting request may bounce back to the sender.
How should I fix it? Microsoft already has an official support article that talks about the named props limit handling which is linked in the above linked article from MS Exchange Team. Following that article would be enough.
At the end, I tried explaining the stuff to the best of my understanding. If you think that this post could have some more detailed information please do feel free to comment or write to me directly using the contact form. I will update the post accordingly.