Receiving NDRs in Exchange 2003

Posted on 2008-11-10
Last Modified: 2012-05-05
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.
Question by:kellyp1
    LVL 12

    Accepted Solution


    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".  

    Author Closing Comment

    Thank you for the explanation and solution!

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Better Security Awareness With Threat Intelligence

    See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

    Get an idea of what you should include in an email disclaimer with these Top 5 email disclaimer tips.
    Create high volume marketing opportunities using email signatures with these top 10 DOs and DON'Ts of email signature marketing.
    In this video we show how to create an Address List in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Organization >> Ad…
    In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment. The video tutorial explains the basics of the Exchange server Database Availability grou…

    794 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    16 Experts available now in Live!

    Get 1:1 Help Now