Udostępnij za pośrednictwem


Figuring out which client was used by the sender to send an email

I have had several customer requests in the past who wanted to figure out what client was used to send an email from a specific mailbox in their Exchange environment (eg: want to figureout whether OWA/Outlook/ActiveSync/EWS etc. was used to send an email)

The simplest and the easiest way is to look through your Message Tracking logs.

In Exchange 2010, we introduced this field in the message tracking logs called as original client IP address.

This captures the machine IP that was used to send an email. This does not show up in your Get-MessagetrackingLogs commandlet by default on Exchange 2010.

So, you will have to manually get into the message tracking log file (based on the time the email was sent) from the mailbox server and look for the message ID for the email being sent. The message ID is something that could be found from both your Get-MessageTrackingLog as well as the message header from the recipients mailbox.

MessageTrackingLog2

 

In the above screenshot of an email sent from one of the user using Outlook when you run the commandlet Get-MessageTrackingLog using EventType as Submit, we see that it did mention that the client used was MOMT (look at the SourceContext field).

ClientType:MOMT

Here are the various Client Types and their meaning.

ClientTypeDefinition

MOMT - expands to Messsaging On Middle Tier (means Outlook client).

If you are using OWA to send an email, you would notice ClientType as OWA

Now that we know what type of client is being used, how do we know what was the IP address from which the email was submitted?

Well, in Exchange 2010 there is no simple way like Get-MessageTrackingLog and you will have to depend on searching through Raw message tracking logs on the mailbox server on which the users mailbox database is mounted  to find out which Transport server the Email was submitted from the Mail submission part of the mailbox server.

If you are having more than one multi-role servers in the same AD site, the submission service will always try to submit the email to the transport service other than itself preferably. Only in case where it couldn't submit an email to other servers, it will try to submit to the transport service locally on the server.

So, go to the Exchange install directory (you can get that by looking at the inbuilt variable $exinstall from your Exchange management shell)

ExplorerExInstall

Under V14, go to TransportRoles\Logs\MessageTracking

You will notice a large number of Tracking log files under MessageTracking folder.

RawTrackingFile

But as you can notice, since the above screenshot is from my lab, you do not notice a large number of files here.

Look for the file name MSGTRKM********-*.log around the time that the message was sent.

Note - The file name is MSGTRKM and not MSGTRK.

MSGTRKM means a message tracking log generated by the submission part of email from the mailbox server and MSGTRK logs are the ones contain the further information about what happened to the email when the message is in transport pipeline.

You can copy the MSGTRKM log files to a machine which contains Excel and filter it out for the MessageID that you obtained from the above Get-MessagTrackingLog command.

You will notice the Hub Transport Server the message was given to under the Server-Host-Name Header. Once you obtain that, you open up the message tracking logs generated during the time of this email submission from that particular Transport server (obtained under Server-Host-Name header) and then filter that for MessageID again.

Also filter the obtained results for Event-id "Receive"

You must now notice only one line as mentioned in the screenshot below.

EventIDAndMessageIDFiltered

Here, if you scroll right at look at the column "original-client-ip", you notice the IP address of the client machine from which the client submitted the email.

In Exchange 2013, this task is much simplified as we have introduced the OriginalClientIP address attribute in the Get-MessageTrackingLog commandlet.

2013Tracking2

Now, if you are wondering why you aren't seeing the correct IP of the client machine, there could be several reasons behind that. Few of them are listed below:

  1. You have a Load balancer which masks the client IP address and stamps the connection coming to the server with its own floating IP address.
  2. You have client coming from internet and the client comes through a firewall/Proxy server which masks the IP address of the client machine.

If there is a user account which gets compromised and sends out large number of spam emails, you can now quickly figure out what type of client is being used to send emails out and take actions against such clients for that user.

For more information on the fields in Message Tracking Logs, please refer: https://technet.microsoft.com/en-us/library/bb124375(v=exchg.160).aspx

Comments

  • Anonymous
    July 12, 2016
    Awesome :) this will help me
  • Anonymous
    July 12, 2016
    Great article Akshay!
  • Anonymous
    August 05, 2016
    Awesome stuff. Great article, to the point and one of its kind in such scenarios.
  • Anonymous
    November 14, 2016
    Nice Read