Exchange 2007 - How to track messages that should be relaying through Exchange

I have a receive connector setup in Ex2007 to allow some of the application servers on our LAN to relay through Exchange.  I used this article to create and configure the receive connector: .  This works just fine for most servers, however we have one project management application server that this feature fails on intermittently.  I need to be able to track these messages to determine at what point they are failing.  The application server only asks for the ip address and port (25) of the mail server, it doesnt ask for any username/password to authenticate with.  Using the message tracing feature in EMC I am unable to find any of these messages, whether they failed or whether they were successful.  

Personally, I do not think that Exchange is the issue, I think it is something faulty with the software application of the application server.  However, in order to prove this to the vendor of this application I need to be able to track the message to determine whether it is not relaying through Ex2007 or whether it is not even reaching Ex2007.  What's the best way to do this, either with Exchange or with some other utility.  Thanks in advance.

Who is Participating?

Improve company productivity with a Business Account.Sign Up

shauncroucherConnect With a Mentor Commented:
Yes they should still be logged. Are you certain you have logging enabled on the correct Receive connector? Is the application definitely sending to this same connector.

you say it is an intermittent fault. Do you see the messages in the log file when the message is successfully sent? If you do, but do not see the message in the log file when there is a failure then I would say the application has not sent it, there really is no other explanation. Are your exchange queues clear?

Exchange Management Console --> Toolbox --> Queue Viewer


The article you are referencing does not suggest using authentication to relay mail. It talks you through creating a scoped connector that only the application server can use (scoped by IP address).

So this is very easy to test from the application server using telnet.

From application server open command prompt and type following commands:

telnet mailserver 25
EHLO applicationservername
mail from: [whatever you use on your application software]
rcpt to: [an email address to receive the mail]
[some text]

Note full stop to end transaction.

If this says mail queued for delivery, the exchange server accepts anonymous messages for relay. If you get an error along the way, exchange does not accept anonymous messages for relay.

To track..
all you need to do is enable verbos logging on the receive connector.
and then restart the transport.
This will create a send connector log.
you can open it and you will find all the connections through the exchange / or on the exchange in it.

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Alternatively you can suspend the submission queue on the Exchange 2007 server. Use the application to send a few emails and see if they arrive in the queue.

Exchange Management Console --> Toolbox --> Queue Viewer --> Select Submission --> Actions Pane --> Suspend.

Note that this will stop mail flow on the server for everyone though! Resume afterwards using Actions Pane.

shockeyAuthor Commented:
I've already tested via telnet from the application server and am able to successfully send mail.  If I recall correctly, those messages via telnet were also viewable in the Ex2007 message tracker.  I'm in the process of enabling the verbose logging for this receive connector now...
You know the server is accepting messages because your telnet test succeeds.

So that is the confirmation you need isn't it? As long as the message has been accepted by Exchange, if it subsequently fails it MUST generate a Non-Delivery report to the sender of the message (or subsequent email servers MUST generate a NDR) which I assume you are able to review?

Logging will give you a decent record of events, so worth doing, but it's looking like it is most likely an issue with the vendor software to me.

Good luck

SurajConnect With a Mentor Commented:
verbos logging will be the best thing !
let me know the results
shockeyAuthor Commented:
so what happens if I can telnet from the app server and it works, but the email sending feature of the application on the app server intermittently fails and I cannot seem to locate any of these messages in the verbose logging of the receive connectors?  The software on the app server says the message was successfully sent, but we are sending test messages from it to local outlook accounts and also to external hotmail accounts and they are being received at either location.  no ndr is generated either.  as stated above, I am sending via the relay receive connector that was created based on that article I mentioned, which allows relay without authentication.  would these type of messages even be logged?  
shockeyAuthor Commented:
i dont think the messages are reaching exchange.  i've installed SMTP View on the application server and do not see any connection attempts from this server to Exchange while monitoring SMTP View and sending test messages.  thanks for reminding me to enable the verbose logging on the receive connectors.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.