Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
A non-delivery report (reason code <reason code>) is being generated for message C=US;A= ;P=MYORG;L=CORPEX01-010206200419Z-572. It was originally destined for DN:/o=MYORG/ou=CORP/cn=RECIPIENTS/cn=<name> (recipient number 6), and was to be redirected to . [MTA DISP:RESULT 18 136] (12)
|English: Request a translation of the event description in plain English.|
|Concepts to understand:|
What is the role of the Exchange MTA Service?
We have seen this message when an Exchange custom recipient is deleted and someone tries to send an email to that account BEFORE the global address list is recreated. However there are other potential reasons for this message to occur. There are many Microsoft articles with information about this event: ME160947, ME169676, ME170535, ME176127, ME176952, ME180547, ME181952, ME184681, ME186258, ME186672, ME191947, ME230497, ME241632, ME246388, ME251016, ME254264, ME259343, ME270695, ME288848, ME302394, ME302451, ME320225, ME328654, ME819851.
Reason code unable-to-transfer and diagnostic code maximum-time-expired: As per ME169715, it is usually an indication that one or more of the servers involved has an incorrect system date or time setting.
See ME197058, ME230748, ME231799, ME254818 and ME262146 for information about this event.
A non-delivery report (NDR) is sent to the originator of a message. It indicates which message was not delivered and why. See MSEX2K3DB for information to troubleshoot this problem.
As per Microsoft: "This issue can occur if a rule automatically forwards all messages sent to a particular mailbox to another mailbox or group of mailboxes. If one or more of the target mailboxes are deleted, an NDR is generated and returned to the sending mailbox, which creates a message loop local to that server". See ME249796 for more details.
Also check ME170471, ME184113, ME224987, ME836563, and ME841834 for more details.
From a newsgroup post: "If the mailboxes that are shown in the recipients portion of the description are all old mailboxes that are now hidden, most likely, this error is from people who have copied the Global Address List entry to their Contacts list and are still addressing the hidden mailbox using that entry (the x.400 address). There's nothing wrong with your system. You might want to instruct your users to address messages out of the GAL if at all possible. There are only a few good reasons to ever copy GAL entries into Contacts lists (synching with PDA's, personal distribution lists)".
From a newsgroup post: "This event can be caused by the fact that either, you have a limit placed on the message size allowed to pass through the MTA or you have placed a restriction on which users can send messages through the IMS. These settings are sure to generate many events, most of them benign".
This error occurs if you have a mailbox that is forwarded to a user and this user does not exist anymore. For example if the user has been deleted without removing or changing the Forward rule of the specific mailbox. See ME254264 for more details.
Woodrow Wayne Collins
ME247133 gives a list of KB articles explaining MTA basic concepts and troubleshooting.
For the description of MTA diagnostics logging options see ME153188.
"Reason code unable-to-transfer and diagnostic code loop-detected" - If it's not a single server environment, try the following suggestions below:
1) Make sure that there are no connectivity issues between the Exchange 5.5 server. Check DNS, HOSTS and LMHOSTS entries on the server and verify that those files (HOSTS and LMHOSTS) has correct entries pointing to the correct servers.
2) Review the GWART0.DAT and GWART1.DAT files from the Exchange Server in the Sending Site. This should indicate the route(s) mail intended for Destination Site should take. Then you can further review the GWART files within the sites the mail passes through en route to the Destination Site.
For example, the following are routing entries from a GWART*.DAT file from a Sending Site. Specifically, the entry below shows the route mail should take to reach the intended Destination Site, where the Destination Site's Directory Name is BELLEVUE. In this example, the Intermediary or Hub Site is named BELLINGHAM:
X400 TO BELLINGHAM, 0002
/O=FWWB/OU=BELLEVUE OFFICE/../CN=X400 TO BELLINGHAM
/O=FWWB/OU=BELLINGHAM/../CN=X400 TO BELLEVUE
If the information is wrong, try the following:
Run DS/IS consistency checker
Recalculate routing on the MTA
Recalculate routing on the site addressing
Turn logging on the MTA (Then look at the application log again)
Stop and start the services.
Also see Microsoft article "Size Limits May Cause Message Looping" - ME160534 and ME278444.
See also the "MTA Troubleshooting Guide" link.
Reason code: unable-to-transfer, unrecognised-OR-name
This event also occurs, when the mailbox of the named user is full and e-mails cannot be delivered to it. Search for event ID 8528 which tells you that this special mailbox cannot get further e-mails or check the actually mailbox size of the user.
This error also occurs in the situation where IIS was re-installed after the Exchange installation. When you re-install IIS the SMTP default Virtual Server for IIS is installed again, and this is causing a conflict with Exchange. At the moment you want to send or receive SMTP messages Exchange will use the IIS SMTP and this virtual server will not know what to do with the messages. So if you re-install IIS, also re-install Exchange server and its service packs to have the proper SMTP Virtual server again.
|Private comment: Subscribers only. See example of private comment|
|Links: ME153188, ME160534, ME160947, ME169676, ME169715, ME170471, ME170535, ME176127, ME176952, ME180547, ME181952, ME184113, ME184681, ME186258, ME186672, ME191947, ME197058, ME224987, ME230497, ME230748, ME231799, ME241632, ME246388, ME247133, ME249796, ME251016, ME254264, ME254818, ME259343, ME262146, ME270695, ME278444, ME288848, ME302394, ME302451, ME320225, ME328654, ME819851, ME836563, ME841834, MTA Troubleshooting Guide, MSEX2K3DB|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
Send comments or solutions
- Notify me when updated