Email Router Demystified – Tools for Troubleshooting - Message Analyzer

Author note: As you’ll notice with most of my blog posts, they tend to have a lot of information and are a bit long.  Instead of sacrificing content, I’ll break up the posts into a series for posts.  This way people don’t get overwhelmed with the amount of content but for those that want the deep technical details, they get that as well.

This article covers Message Analyzer and is the third article within the Email Router Demystified – Tools for Troubleshooting blog series.  To get to a list of the other tools, go HERE.

Message Analyzer is such a neat tool developed by Microsoft.  Message Analyzer allows you to capture all sorts of different data at the same time.  For the purpose of this article, we will be using it simply as a network capturing tool.

You can get Message Analyzer here.

The install is pretty straight forward so we are not going to really cover any of the installation parts. 

Network Monitoring Configuration

After installing Message Analyzer, you will need to do the following in order to capture network traffic

1. Open it up and you will create a “New Session”
2. Within the New Session window, click on Live Trace
3. Under ETW Providers, click on “Select Scenario” and go to “Local Network Interface"
   
4. Now depending on what type of traffic we want to capture, we can apply filters so that we limit the amount of data we have to review.  In the case of the Email Router, we can define a filter for the port based on the require ports for SMTP and/or POP3.  The default port for SMTP is 25 and POP3 is 110 for non-SSL and 995 for SSL traffic.  However, these will be different based on the email provider.  For instance, Outlook.com uses 995 for POP3 and SMTP is 25 or 587 whereas Gmail uses 995 for POP and 465 for SMTP.  In my test environment, I am using 25 for SMTP and 110 for POP3:
   
5. Now we click on Start

Data Analysis

On the surface, the data being shown within Message Analyzer can be a little overwhelming. 

Aliases

What you are going to need are the IP addresses for every server you want to monitor the traffic on.  This can help us figure out the traffic flow between CRM and the email server.

In my test environment, the IP addresses in play are:

Knowing that, I can make analysis a little easier by adding some aliases for the IP Addresses.  To do this, I can right-click on the IP address within the Source or Destination column and go to “Create ‘Source’ Alias”:

Now I enter in the alias of my CRM server name (it has the .51 address) and click Save

I do the same thing for the Exchange server and now I can easily see where the requests came from and went to in the trace:

Filters

Next, I need to add filters to get data that is relevant to what I am looking for.  When adding filters, I am going to try and filter the data as much as possible because the traces can end up getting pretty large.  When we started the trace, we added some prefilters but I can do the same thing and add additional filters or if I didn’t add prefilters, I can add the filters now.  In this case, I am only going to take a look at the SMTP traffic:

Packet Analysis

Now that I have the data filtered to the data I want, I can now see the request and the response within Message Analyzer.  Now this is great for unencrypted data but not so great for traffic using TLS or SSL.  However, even if we have to review encrypted traffic, we can get some sense of what is happening if we capture unencrypted traffic just to see what commands are being sent.

Again, we can spend a ton of time talking about the data returned by Message Analyzer and how to get the most out of the data but, for this article, we are simply going to focus in on the traffic.

If I look at the traffic, I can see that we start with the three way handshake and then CRM starts the requests. 

1. The first request is a simple EHLO request and we are simply looking to get a Hello response back from the email service
   
2. Once that is done, we are simply doing basic SMTP commands
   1. MAIL FROM
   2. RCPT TO
   3. DATA
   4. After that is complete, we close the connection by doing a QUIT

So this is helpful to an extent, especially if it’s unencrypted data.  We can simulate the same request by using TELNET.

We start off by establishing a connection to the email server (this should be the same server and port used in your Outgoing profile):

Now I simply do the same things we do as we saw in the trace:

We can get more details of what was the content of the email by looking at the payload from the MailPacket frame:

We can apply that same concept to POP3:

However, TELNET only works with unencrypted connections.  If we are going to try to test an encrypted connection, you’ll have to use something like OpenSSL to test the connection.  The commands are the same it’s just using a different application:

Again, we are using different tools to try and help us figure out where the issue lies.  In this case, we are looking to see if the traffic is making it to and from the POP3 or SMTP server.  If it is, are we able to make the same requests with other tools or is the issue simply with the email router?  Using a combination of these tools allows us to confirm where the issue lies.