Less than useful NDR

Simon or anyone else, have you ever seen a blank NDR from Exchange? There is a user trying to email a legimate email address on a Exchange server I manage, and all they get in exchange is an NDR message with no error code, it reads as follows:

Subject: Delivery Status Notification (Failure)

This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed.

       [removedforprivacy]@[removedforprivacy].com



Looking on the Exchange server Message Tracking Center, I have pulled up this log, and all it is saying is:

3/28/2007 5:46 AM SMTP: Message Submitted to Advanced Queuing
3/28/2007 5:46 AM SMTP: Started Message Submission to Advanced Queuing
3/28/2007 5:46 AM SMTP: Message Submitted to Categorizer
3/28/2007 5:46 AM SMTP: Message Categorized and Queued for Routing
3/28/2007 5:46 AM SMTP: Non-Delivered Report (NDR) Generated


I am not sure where to proceed from here. Usually I would take the NDR error reason and troubleshoot, but obviously I can't this time around.
newgentechnologiesAsked:
Who is Participating?
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.

Hypercat (Deb)Commented:
Do you have SMTP logging turn on on this machine?  If not, turn it on, set it to NSA logging format (which is easier to read), try to resend to the same address and then check the log.  This will tell you at least if your server is even trying to connect to an external SMTP server.
0
SembeeCommented:
Have you checked the domain is alive?
Have you tried to telnet to the MX records of that domain from your Exchange server?

I have seen this when there have been routing problems. As an interim measure sending the email via the ISP on an SMTP Connector resolved the problem.

Simon.
0
newgentechnologiesAuthor Commented:
hypercat:

Logging is on. Where do I enable NSA?

Sembee:

I am unsure what you are suggested. Can you give me more detailed instruction to get it accomplished? Thanks.
0
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics ā€“ known as key performance indicators (KPIs) ā€“ for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

SembeeCommented:
0
newgentechnologiesAuthor Commented:
Well, this problem is only happening with this one .com domain on the Exchange server, other ones work fine. It's also only with some recipients, I am able to email this problem .com address from my Exchange email account, and also my Gmail account. I am trying to troubleshoot why these few senders are not connecting properly to the recipient, and what the NDR might be, but as I have said, the NDR is blank so it's hard to troubleshoot anything.
0
newgentechnologiesAuthor Commented:
Anyone?
0
SembeeCommented:
Have you done any troubleshooting to see whether you can connect to the remote domain? It was asked earlier and there is no evidence that you have done so.
If it is one domain have you spoken to whoever operates that domain to find out if they are blocking your messages?

Simon.
0
Hypercat (Deb)Commented:
The logging format is set on the general tab in the properties of the SMTP virtual server. When you click the Enable logging checkbox, the dropdown below is activated to choose the format. I mistyped - it's "NCSA common log file format" not NSA.

Do you have any spam filtering software on your server?  If you have and it's filtering outgoing email, this just might be where the NDR is coming from.  Check any related logs as well.

Simon suggested a telnet test and that's a good suggestion.  To do this, open a command prompt and type "telnet [mailservername] 25". You should get a banner response from the email server identifying itself and acknowledging the connection.  Then use the commands described on this page to communicate with the email server:

http://www.the-welters.com/professional/smtp.html

(This is a very old page and nothing flashy, but it still works after all these years!)
0
newgentechnologiesAuthor Commented:
I can connect to the mail server fine, myself and many others have never had a connection issue. Only a small amount of people cannot email the contact, and they are the ones getting the NDR. I tried emailing the user from my Exchange server account, and from my Gmail account, and he recieved both the emails.
0
Hypercat (Deb)Commented:
Did you connect to the email server of the person that is having trouble sending you email? I understand that your user can receive email internally and, for the most part externally.  However, you need to test the SMTP gateways at both ends.  You can do two tests:

1.  Telnet to port 25 on your email server, use the external sender's domain name in the EHLO command, and use the external sender's email address on the "MAIL FROM:". Then use your internal user's email address on the "RCPT TO:" Send the email and see if he receives it.  You should perform this test from an external location if at all possible.  Ideally, you should have someone from the other company perform this test from their location.

2.  Telnet to port 25 on the sending user's email server, use your domain in the EHLO and MAIL FROM and the sender's email in the RCPT TO and see if that works.
0
newgentechnologiesAuthor Commented:
hypercat, step 1 worked fine, the message was delivered to the recipients mailbox in Exchange, this is what I did:

1. I accessed my client's (the one who is not recieving the email properly) Exchange server, and then a telnet to the internal Exchange server.
2. In the EHLO command, I used the sender's domain.
3. In the MAIL FROM: command I used the sender's email address.
4. In the RCPT TO: command I used my clients full email address.
5. Entered "test email" for the DATA command.
The internal mail server I was telneted to reported "Queued mail for delivery", then I quit.

Looking on the server in the logs (after I had gone and switched them to NCSA), I found the following log entry:

From: [sender who couldn't reach my client]
To: [recipient who couldn't get the emails]
Subject: [blank]

SMTP: Message Submitted to Advanced Queuing
SMTP: Started Message Submission to Advanced Queue
SMTP: Message Submitted to Categorizer
SMTP: Message Categorized and Queued for Routing
SMTP: Message Queued for Local Delivery
SMTP: Message Delivered Locally to [recipient who couldn't get the emails]
SMTP Store Driver: Message Delivered Locally to Store to [recipient who couldn't get the emails]




0
Hypercat (Deb)Commented:
Ok, so we know that it is not your SMTP gateway that is rejecting the internal email address.  However, that is a message log, not an SMTP log.  The SMTP logs are found on your Exchange server in the C:\%systemroot%\system32\logfiles\SMTPSVC folder (folder name might have a number after it).  The inbound communication should look something like this (IP addy's and server names changed for privacy):

2.3.4.5 - server.domain.com [30/Mar/2007:00:22:25 -0500] "EHLO -? server.domain.com SMTP" 250 314
2.3.4.5 - server.domain.com [30/Mar/2007:00:22:25 -0500] "MAIL -? FROM:<Administrator@domain.com> SMTP" 250 47
2.3.4.5 - server.domain.com [30/Mar/2007:00:22:25 -0500] "RCPT -? TO:<help@mydomain.com> SMTP" 250 34
2.3.4.5 - server.domain.com [30/Mar/2007:00:22:25 -0500] "xexch50 -? 2728 2 SMTP" 504 32
2.3.4.5 - server.domain.com [30/Mar/2007:00:22:28 -0500] "BDAT -? <BD2F4B32A56AD04A9FFA74F2C5FB00FF159C74@server.domain.com > SMTP" 250 93
2.3.4.5 - server.domain.com [30/Mar/2007:00:22:28 -0500] "QUIT -?server.domain.com SMTP" 240 72

If you can get the user who is getting the NDRs to try to send your user another email, then you can search this log to see what's happening at the gateway.  It could still be a problem at the gateway, esp. if you have some type of spam filtering going on.
0
newgentechnologiesAuthor Commented:
This is the information the log is giving so far:

216.118.97.139 - watt.mywebserver.net [31/Mar/2007:05:13:06 -0800] "EHLO -? watt.mywebserver.net SMTP" 250 217
216.118.97.139 - watt.mywebserver.net [31/Mar/2007:05:13:06 -0800] "MAIL -? FROM:<x@xxx.com> SMTP" 250 44
216.118.97.139 - watt.mywebserver.net [31/Mar/2007:05:13:06 -0800] "RCPT -? TO:<x@thepersonwhocantrecievetheemail.com> SMTP" 250 0
216.118.97.139 - watt.mywebserver.net [31/Mar/2007:05:13:06 -0800] "DATA -? <001b01c7738d$f2007e10$6500a8c0@Toshiba> SMTP" 250 124
216.118.97.139 - watt.mywebserver.net [31/Mar/2007:05:13:06 -0800] "QUIT -?watt.mywebserver.net SMTP" 240 64

No NDR is present.

I asked the sender to email the recipient 5 times, and in the log I see him sending the recipient 5 times, and then I see the server emailing him back 5 times (im guessing this is the NDR).
0
Hypercat (Deb)Commented:
That log substantiates my comment that the SMTP gateway is not what is rejecting the email or generating the NDRs.  What does Exchange message tracking show on these attempts?  Is it the same as what you showed in your original post?  The messages appear to be getting stuck or misrouted somehow between the categorizer and the local delivery queue.  Do you have diagnostic logging turned on and are there any errors in the application log? Again, as I asked before is there any spam filtering going on here - do you have the Intelligent Message Filter configured or a 3rd party spam filter?
0
newgentechnologiesAuthor Commented:
Message Tracking Center is showing the same as I posted originally. I do not know of any diagnostic logging that might be turned on, where do I check this? As well, which application log are you referring to?

IMF is setup, with method set to Archive.
0
Hypercat (Deb)Commented:
In the ESM, go to the properties of the server, diagnostics logging tab. Click on MSExchangeTransport and highlight all the items and then select Medium for the logging level.  The log entries will go into the Event Viewer Application Log (that's the application log I was referring to).  Have the problem user try sending email to your internal user.  Once that email has been sent and you can see it in the message tracking center, turn off the diagnostics logging (so that it doesn't fill up your app log) and check the messages to see if there's any relevant info there.  

And have you checked the IMF archive to see if the messages are ending up there?
0
newgentechnologiesAuthor Commented:
I'm not quite following what you are saying in your instructions, do you mind repeating with some more thorough information?

The IMF Archive did not have any of the messages in it (since they aren't spam)
0
newgentechnologiesAuthor Commented:
Oh, and diagnostic logging is on, has been for quite some time.
0
Hypercat (Deb)Commented:
There are lots of different selections and levels for diagnostics logging.  If you aren't seeing any Event Viewer entries from the MSExchange Transport engine, then you should increase the logging, at least temporarily, while we troubleshoot the problem.  To check and/or increase the diagnostic logging level:

1.  Open the Exchange System Manager.
2.  Drill down through the levels until you see the server name. Right-click on the server name and click Properties.
3.  Click on the Diagnostics Logging tab in the Properties dialog.
4.  On the left-hand side, there is a Services list.  Click the MSExchangeTransport server.
5.  On the right-hand side, on the Categories list, you'll see a bunch of different events that can be logged.  Highlight all of them (you can click the first and then CTRL-click the last to highlight all).  Then, below the lists, click the radio button that says Medium.  If Medium is already selected, then click Maximum.

After that is set, try a test again with the external user sending an email.  Check the application log for the related events.  There should be a group of entries, mostly probably informational only, but you should check all of them. Certainly if there are any warnings or errors, check those carefully.

This can also be done in the registry if you need to set it higher than Maximum (Field Engineering level).  Here's an article on how to do this:

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

0
newgentechnologiesAuthor Commented:
What type of events should I be looking for in order to diagnose the problem? These diagnostic logs have already been enabled for months now.
0
Hypercat (Deb)Commented:
What logging level are they set at?  First of course you want to look for any error messages, then check warning messages.  Anything related to Exchange could be relevant, but especially anything from the MSExchangeTransport source. If the only messages you see are informational only, then it's not going to be of much help.

Something is not quite right here.  You say that you see that he sent 5 messages and the server sent 5 messages back.  Did your user not get any of these messages?  Do any users in your organization receive this guy's messages?  When he gets an NDR, is it from postmaster@yourdomain.com?  
0
newgentechnologiesAuthor Commented:
Current levels are set to medium.

The recipient did not get any of the 5 messages, they went from the sender to the server, and then from the server back to the sender.

The NDR is coming from postmaster@yourdomain.org
0
newgentechnologiesAuthor Commented:
I just got the sender to try to email my recipient again.

In the Message Tracking Center, at 2.59pm, I see the sender trying to send to my recipient which causes a NDR, and then immediately after I see postmaster@mydomain.org mailing the sender back with a 'Delivery Status Notification (Failure)'.

In the Event Viewer in the Application Log, I don't see anything at the same time as the on-goings in the Message Tracking Center.

How should I proceed?
0
Hypercat (Deb)Commented:
So it appears that something in the server configuration is blocking the emails.  You need to check the IMF and any other filtering settings you have on that server (sender and/or IP filtering, content filtering, etc.) - that's the only other thing I can think of that would block those messages.  
0
newgentechnologiesAuthor Commented:
Doesn't IMF always reply back to the sender with an error code, at the minimum?

Currently IMF is setup as Block 7 with archive, and Move 5.
0
newgentechnologiesAuthor Commented:
Anyone?
0
Hypercat (Deb)Commented:
I have not used the IMF myself, so I'm not that familiar with the various setting levels.  I was thinking more of the other filtering settings in Exchange, such as sender filtering, sender ID filtering and connection filtering.  Are any of those turned on and configured?  One thing, just as a test, would be to turn off the IMF and do a test from him.  I know that's not ideal, but it may be the only way to prove whether something in that configuration is blocking his emails.
0

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
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
Exchange

From novice to tech pro — start learning today.