none
Email Delivery Failure Error #4.4.7 Exchange 2003

    Question

  • We are having a mail delivery problem with Server/Exchange 2003.  When trying to send an email to selected domains, the emails are returned with the following error message (the actual user id and the server domain in the error message have been removed for privacy purposes): 

     

    Your message did not reach some or all of the intended recipients.

          Subject:  Testing E-mail

          Sent:     11/04/2008 9:50 AM

    The following recipient(s) cannot be reached:

          USERNAME@lawsociety.mb.ca on 11/04/2008 10:53 AM

                Could not deliver the message in the time limit specified.  Please retry or contact your administrator.

                <Our_Domain #4.4.7>

     

     

    Notes:

     

    - This has just begun to happen approximately one month ago.  Prior to this happening, there were no changes on the server, including no service packs installed. 

    - The emails to the domains now causing an error were working in the past, or believed to have been working. 

    - We have since installed all available service packs and/or patches, with no effect. 

    - We have both and SMTP connector and a POP connector. 

    - There are no error messages in the event log corresponding to the times that the emails are sent. 

    - If we log into Webmail on MTS.ca (our POP provider) and send an email to the account generating an error, the email is delivered correctly.   

    - Outlook 2007 was installed on the client computers at approximately the same time as when the errors began to appear.  The Webmail app has not been updated to a newer version.  MS Office is not installed on the server. 

     

     

     The trace log for the failed email is: 

    4/14/2008 8:35 AM SMTP Store Driver: Message Submitted from Store

    4/14/2008 8:35 AM SMTP: Message Submitted to Advanced Queuing

    4/14/2008 8:35 AM SMTP: Started Message Submission to Advanced Queue

    4/14/2008 8:35 AM SMTP: Message Submitted to Categorizer

    4/14/2008 8:35 AM SMTP: Message Categorized and Queued for Routing

    4/14/2008 8:35 AM SMTP: Message Routed and Queued for Remote Delivery

    4/14/2008 8:35 AM SMTP: Non-Delivered Report (NDR) Generated

     

    The trace log for a successful email is (removed the server id for privacy):

    4/14/2008 8:33 AM SMTP Store Driver: Message Submitted from Store

    4/14/2008 8:33 AM SMTP: Message Submitted to Advanced Queuing

    4/14/2008 8:33 AM SMTP: Started Message Submission to Advanced Queue

    4/14/2008 8:33 AM SMTP: Message Submitted to Categorizer

    4/14/2008 8:33 AM SMTP: Message Categorized and Queued for Routing

    4/14/2008 8:33 AM SMTP: Message Routed and Queued for Remote Delivery

    4/14/2008 8:33 AM SMTP: Started Outbound Transfer of Message

    4/14/2008 8:33 AM SMTP: Message transferred to XXXXXor2.XXXX.com through SMTP

     

     

    I can’t seem to figure out what the problem is.  Since the email can be delivered successfully from the same account using MTS.ca webmail, the problem must reside on our server, or between our server and MTS. 

     

    Any help would be greatly appreciated.  I am running out of hair to pull out!

    Sunday, April 20, 2008 10:45 PM

All replies

  •  

    HI,

     

    Per my understanding, your current issue is related to an NDR message with status code error 4.4.7 was received when trying to send outbound message with own server. You have tested to send via Webmail, it is successful. Meanwhile, from your post, it seems that you are using only one SBS server with Exchange 2003 Server.

     

    If there is any misunderstanding, please feel free to correct me.

     

    Per my experience, we can follow below troubleshooting steps to narrow down the issue.

     

    Step 1: Use NSLookup to check MX Record

    ================================

    1.      Run below commands in the CMD console on your Server.

     

         NSlookup –q=mx <the remote server domain name, “lawsociety.mb.ca”>

     

    If it can find the MX record and IP successfully, please follow the next steps to test SMTP Service.

     

    Step 2: Test SMTP Service by Telnet

    ===========================

    1.      Still in the CMD console, please type below commands.

     

         >telnet < one of IP address for MX record> 25

    If it is connected, let us use below SMTP verb to send a test message.

         >Helo

    If you have typed correctly, It will return 250.OK.

         >Mail From: <Sender’s Email address>

    If you have typed correctly, It will return 250.OK.

         >Rcpt to:<recipient’s EMial address>

    If you have typed correctly, It will return 250.OK.

         >Data

    After pressing Enter, please type the Email content and end it with the dot(.) to send a test Email

     

    If you have any problem how to use the SMTP verb to test SMTP server, please refer to below KB article.

    How To Test SMTP Services Manually in Windows Server 2003

    http://support.microsoft.com/kb/323350/en-us

     

    If the NDR issue still persists, please check Queue viewer for further information. In the ESM, Expand Administrator Group->Server->Queue. If possible, please let me the detailed Queue information in your server.

     

    How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003

     http://support.microsoft.com/kb/823489/en-us

     

    For your reference, below is a troubleshooting KB article about the NDR code: 4.4.7

     

    Delivery status notifications in Exchange Server and in Small Business Server

    http://support.microsoft.com/kb/284204/en-us

     

    thanks,

     

    Jason

     

    Monday, April 21, 2008 3:40 AM
  • hi

    i am facing the same issue here some of my users are trying to send the email but everytime it bounces back and the same error code generates 4.4.7

    i just want to know the information you have provided in the step 1. what if i cannot find the MX record .what do you think then the problem will lie whether it will on my end or the recieving partys end .

     

    Friday, August 22, 2008 1:16 PM
  • I'm having the exact same problem on my SBS2003 server. It also apparently came out of nowhere. In addition to your information, I have found that rebooting the server makes all of the email flow normally again for about a week. It takes from approximately a week to ten days for the 4.4.7 errors to start showing up again.

    To dispell any theories on mx records, routing tables etc... the email addresses my users are sending to are always the same. Day in and day out, they send to the same recipients using the same routine process. When the blockage occurs, I have to restart the server to get the mail to flow normally.

    Please... Any help would be MUCH appreciated!

     

    Marcus

    Tuesday, September 20, 2011 1:07 PM
  • I have the same issue with a client on SBS2003. It looks like it started Friday the 16th but they didn't notice it until yesterday. They were receiving mail fine, Internet access was good and no other issues were happening they were aware of. A couple of their clients called them asking about the email they were suppose to receive.

    Everything on the server looks fine, all services that should be running are. Their mail store was about a GB from the limit so I increased the limit, they deleted some old email and I rebooted the server. Checked the queue and all the old email is stil there.

    Art

    Wednesday, September 21, 2011 11:56 PM
  • I had the same issue here, i found that the issue was related to SMIME, I had installed a digital certificate for encrypted email, I was able to send encrypted email fine, just messages that were digitally signed bounced back with error 4.4.7 to certain domains.

    Hope that helps.

    Tuesday, January 10, 2012 11:58 AM
  • I solved this problem as follows:
    Open Exchange Administrator
    In First Administrative Group, Servers, server_name, Protocols, SMTP, SMTP Virtual Server Properties, Delivery, Advance ...
    In Domain Name, enter the right Internet domain.

    Problem was, our internal domain name is different from Internet domain, so when a message arrives to destination some servers checks header and compare with internet address.

    Hope this helps

    Nelson

    Tuesday, June 19, 2012 3:53 PM