Receiving NDRs in Exchange 2003

Several months ago one of our users got a virus that ended up getting our email blacklisted.  I got the virus cleaned up and requested to be removed from the blacklists.  I created a routing group connector through Dyndns to route emails that I could still would not go through.  Things are finally somewhat back to normal.  However, it seems that we are still receiving more NDRs on a daily basis than I am comfortable with.  They are not consistent as far as who is sending or receiving and one that doesnt get delivered today may work tomorrow.  A few of the NDRs received are as follows:  
Could not deliver the message in the time limit specified.  Please retry or contact your administrator. 
The e-mail system was unable to deliver the message, but did not report a specific reason.  Check the address and try again.  If it still fails, contact your system administrator.< #4.0.0 smtp;451 Temporary local problem - please try later>
There was a SMTP communication problem with the recipient's email server.  Please contact your system administrator. < #5.5.0 smtp;550-Callout verification failed:> 
There was a SMTP communication problem with the recipient's email server.  Please contact your system administrator.      < #5.5.0 smtp;550 Sender verify failed>.

Also in the Event viewer I am receiving mutiple Event IDs 7004.  This is an SMTP protocol error log for virtual server ID1, connectuion #3. The remote host "external ip address", responded to the SMTP command "xexch50" with "504 Need to authenticate first". The full command sent was "XEXCH50 2552 2".  this will probably cause the connection to fail.  

I dont recall having so many NDRS and errors in the event log prior to the virus/blacklisting issue.  I have been researching this for so long and cannot figure it out.  I am pulling my hair out and soon the users are going to lose their patience.  Any help at all would be greatly appreciated.

We are running Exchange 2003 on Server 2003.
Thank you in advance for any help that you may give.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

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.


This is what I have found on another site, there are here the same problems and resolutions(kb articles), the post it's a bit long but if you have time to get throw all you will find what you are looking for.

Adrian Grigorof (Last update 10/6/2008):
This is a generic message recorded by the SMTP server component when it received a response from a remote SMTP server that indicates some type of problem with the email message it tries to relay. There can be many reasons for such a transfer to fail. The "full command" sent and the SMTP command that the remote server "responded" contain the relevant information about this problem and the next steps in troubleshooting this should be based on these command, especially the response from the remote server.

For example a response like "550 5.7.1 Unable to relay for ....<user email here>" indicates that the remote server is configured to reject any relay for that particular user and perceives this command (such as RCPT TO: ) as a relay attempt and in consequence will not accept the message.

B. Collins (Last update 2/7/2007):
I noticed this problem after upgrading an Exchange server from 2000 to 2003. Only mail sent to external exchange servers was affected. In highlighting the solution, it is helpful to outline the process that occurs when an Exchange Server 2003 or Exchange 2000 Server-based server tries to send mail to a host over the Internet.

1. It performs the equivalent of an Nslookup for the MX (mail exchanger) record of the remote domain.
2. It opens a TCP/IP connection to port 25 of the remote host.
3. It receives a banner from the remote host.  
4. It sends an EHLO command followed by the local domain name to the remote host.
5. It receives a list of supported commands from the remote host.
6. It sends a MAIL FROM command followed by the e-mail address of the sender.
7. It receives an acknowledgement from the remote host.
8. It sends one or more RCPT TO commands followed by one or more recipient e-mail address.
9. It receives one of the following acknowledgements:
- One acknowledgement after a batch of RCPT TO commands if the remote host supports PIPELINING.
- One acknowledgement for each recipient.

10. If the remote host advertised support for the XEXCH50 command, the Exchange server sends the XEXCH50 command followed by the number of bytes that it intends to transfer, and then the numeral 2. For example, the following command indicates that the Exchange server intends to send 1124 bytes of data: XEXCH50 1124 2
11. It receives a 354 message from the remote host permitting it to send the data.
12. The Exchange server sends the number of bytes of data that it specified in step 10 of this process.
13. When the data has been sent, the Exchange server expects the remote host to immediately respond with an acknowledgement. If there is no more mail to send, the Exchange server sends a QUIT command.
14. The Exchange server receives an acknowledgement of the QUIT command from the remote host.
15. The Exchange server ends the session.

In this case, the remote host is an exchange server who advertises support for the XEXCH50 command and responded to the SMTP command "xexch50" with "504 Need to authenticate first".  By Configuring the XEXCH50 registry subkey, we can suppress the sending of the XEXCH50 command to external domains and resolve the problem. To do so, follow these steps:

1. Click Run, type regedit in the Open box, and then click OK.
2. Locate the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\XEXCH50
Note If the XEXCH50 registry subkey is not present, create it. To do this, point to New on the Edit menu, and then click Key. In the New Key #1 box, type XEXCH50, and then press ENTER.
3. Right-click XEXCH50, point to New, and then click DWORD Value.
4. In the New Value #1 box, type SuppressExternal, and then press ENTER.
5. Right-click SuppressExternal, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Quit Registry Editor.

This information is pretty much a rehash of information found in M818222.

Anonymous (Last update 1/21/2007):
I found that this was caused because I had the local domain name and not the publicly advertised name in the Fully Qualified Domain Name field of the SMTP server Delivery Advanced properties. As an example, my local domain could be Company.local, I had the Fully Qualified Domain Name field of the SMTP server MyServerName.Company.local. My ISP has my mail server advertised as mail.Company.Com. So when I put mail.Company.Com in this field it worked. The problem only occurred when I sent mail to an Exchange server. Mail to non-Exchange SMTP servers worked fine.

Mihai Andrei (Last update 11/18/2006):
This problem occurs when the following conditions are true:
1.The server that is running Exchange Server 2003 has SMTP virtual servers that have a Fully Qualified Domain Name (FQDN) that does not match the server name.
2.The FQDNs for the SMTP virtual servers do not have a Service Principal Name (SPN) registration.
See M914137 to solve this problem.

See M925447 for additional information about this event.

Harvey Liang (Last update 1/2/2006):
According to Microsofts explanation, if you have Symantec AntiVirus Corporate Edition 9.0 installed on Exchange 2000 or Exchange Server 2003, and the Internet E-Mail Auto-Protect feature is enabled, this will happen.
By disabling the Internet E-Mail Auto-Protect feature of Symantec Antivirus Corporate Edition 9.X, messages can be delivered out.

Ionut Marin (Last update 10/25/2005):
As per Microsoft: " This issue may occur if the computer that is running Exchange 2000 or Exchange 2003 is listed as a messaging server that sends unsolicited commercial e-mail (UCE, also known as spam). This behavior may occur if the computer that is running Exchange 2000 or Exchange 2003 is an open mail relay". See M843106, and M895853 to fix this problem.

See M821910 for information on how to troubleshoot for Exchange Server 2003 transport issues. See MSEX2K3DB for more details on this event.

From a newsgroup post: "This is an alert that a host has tried to pass an XEXCH50 command without passing authentication credentials first. The XEXCH50 command is normally only issued between Exchange servers in the same organization. If this is coming from an outside host, someone may be trying to implement a denial of service attack against your server. If you have not already installed the September post-SP3 rollup package for Exchange 2000, you may want to consider doing so".

From a newsgroup post: "If the only problem you are seeing is that XEXCH50 is being denied in some cases, but there is no mail flow problem, it sounds like everything is ok as long as XEXCH50 is only being denied from servers outside of your Exchange Organization and mail is still being received.
Exchange 2003 only accepts XEXCH50 protocol data from clients who authenticate and have been granted "Send As" permission on the receiving SMTP virtual server object in the AD. In this respect, Exchange 2003 behaves differently than Exchange 2000. Within a single Exchange organization, Exchange setup takes care of ensuring that all Exchange servers have the necessary "Send As" right on all of the SMTP virtual servers, through the ACL on the Exchange organization object in the AD which inherits down to all of the SMTP virtual server objects. Because of this, the XEXCH50 command should be properly sent and received between servers within a single Exchange organization. It is expected that Exchange 2003 will block inbound XEXCH50 data from other Exchange organizations by default, and in this regard, the fact that it is responding with "504 Need to authenticate first" is actually correct, if the remote server is not part of the same Exchange organization. If you are seeing this between servers in the same Exchange organization, that is potentially an authentication or ACLing problem that should be looked into. You can use ADSIEdit.msc to investigate the ACLs of the Exchange objects in the configuration container if you suspect that the necessary Exchange server security groups have not been granted the Send As access that they need on the SMTP virtual servers. If you are seeing this between servers in different Exchange organizations, it is normal expected behavior, and should not actually block mail flow. When Exchange 2003 rejects an inbound XEXCH50 attempt, it allows the client to continue without the XEXCH50 data. When Exchange 2000 or 2003 attempt to send an XEXCH50 command and are denied, they continue to try to send their message data".  

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
kellyp1Author Commented:
Thank you for the explanation and solution!
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

From novice to tech pro — start learning today.