Testing and debugging TLS protocol on Microsoft Exchange 2003 server

 Part 5 of a six-part article: The easiest way to test the encryption is to send an e-mail to the e-mail administrator of the domain you just configured and ask him/her to send you back the headers of the e-mail.

Part 5 of a six-part article:

  1. Configuration and Troubleshooting TLS in Exchange Server
  2. What is Transport Layer Security protocol?
  3. How the TLS Protocol Works
  4. How to configure TLS encryption on Microsoft Exchange 2003 server
  5. Testing and Debugging TLS protocol on Microsoft Exchange 2003 server
  6. What do I do if there is no TLS handshake?

The easiest way to test the encryption is to send an e-mail to the e-mail administrator of the domain you just configured and ask him to send you back the headers of the e-mail. The headers will list the path the message traveled from your SMTP server to the other, as well as weather or not it was TLS encrypted. The e-mail headers could also tell you a lot about the nature of the recipient’s network and e-mail server. A good understanding of how to read headers is a necessary troubleshooting skill.

Now let’s examine the following header and see what we could learn from it:

Click to view (popup)

The header essentially shows how the e-mail message traveled from the sender to the recipient. But it is also loaded with other very useful information that can be used in troubleshooting process. The information about the origin of the message is always at the bottom of the header. First it will display time when this message was original arrival time:

X-OriginalArrivalTime: 10 Oct 2006 20:01:51.0389 (UTC) FILETIME=[ED237CD0:01C6ECA6]

This information could be useful when you are trying to debug e-mail problems reported by the user and various investigators also may find this information useful. The next field is the “Return-Path”

Return-Path: admin@my-test.com

This tells you where the Non-deliverable Reports (NDR) are sent. So, if the user says that he never received the NDR, you know where to look.

The Content-Type:

Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ECA6.E3E1952E"

is another MIME header, telling MIME-compliant mail programs what type of content to expect in the message.

The X-WSS-ID is and acronym for Windows Server System ID:

X-WSS-ID: 693523182P810969-01-01

In this case, we could say that the sender sent this message form Windows 2003 server. The convention is that X-headers are nonstandard and provided for information only, and that, conversely, any nonstandard informative header should be given a name starting with "X-". This convention is frequently violated.

The next informative header marked with “X” is X-TMWD-Spam-Summary. The acronym stands for Tumbleweed Communications Corp. This portion of the header functions as a spam marker and in this case the e-mail was not marked as a spam by tags CAT=0; CON=0. It also informs us the recipient is using Tumbleweed as its e-mail gateway.

X-TMWD-Spam-Summary: TS=20061010200333; SEV=2.0.2; DFV=A2006101008; 

IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230372E34353242464245332


Then you get the e-mail addresses of the people who sent and received the e-mail.

From: "Admin" <admin@my-test.com>
To: "e-mail.admin" <eadmin@test.com>

The Thread-Index and Thread-Topic are used for associating multiple messages to a similar thread. For example, in Outlook the conversation view would use this information to find messages in one conversation thread.

Thread-Index: Acbsnlxw+/PzW9SmRguHZSLpvjClIwAAQFjwAAF/ThA=
Thread-Topic: another test packet capture

The next two informative headers marked with the “X” are: X-MS-TNEF-Correlator and X-MS-Has-Attach.


The MS-TNEF is an acronym that stands for Transport Neutral Encapsulation Format, a proprietary format used by the Microsoft Exchange and Outlook e-mail clients when sending messages formatted as Rich Text Format (RTF). When Microsoft Exchange thinks it is sending a message to another Microsoft e-mail client it extracts all the formatting information and encodes it in a special TNEF block. It then sends the message in two parts - the text message with the formatting removed and the formatting instructions in the TNEF block. On the receiving side, a Microsoft e-mail client processes the TNEF block and re-formats the message.

Unfortunately, most non-Microsoft e-mail clients cannot decipher TNEF blocks. Consequently, when you receive a TNEF-encoded message with a non-Microsoft e-mail client, the TNEF part appears as a long sequence of hexadecimal digits, either in the message itself or as an attached file (usually named WINMAIL.DAT).

The X-MS-Has-Attach: informs that the client is ready to send attachments and it also informs whether or not the e-mail contains any attachments. If the e-mail contains attachments the information header X-MS-Has-Attach: will say “yes” after colon.

X-MS-Has-Attach: yes

The In-Reply-to: and Message ID: mean essentially the same thing. The e-mail messages have been given this number by both e-mail servers for identification purposes. These ID numbers always follow the message for life. You can copy and paste them into Message Tracking Center to more information about them. This is very useful information when troubleshooting e-mail routing and all type of forensics.

Message-ID: <E0F93F027183B144B62595406230ACA10220A1DD@mail.my-test.com> In-Reply-To: <E316CF6728FBB74EBCEEF14D1640171A03EFB639@sfs-exmb02.firm.test.com>

Date and Subject fields are self explanatory. However, it is worth noting that the date and time the e-mail message was sent is based upon the computer clock on the sender's computer.

Subject: RE: another test packet capture
Date: Tue, 10 Oct 2006 15:01:35 -0500

The MIME-Version: 1.0 specifies the version of the MIME protocol that was used by the sender. The acronym MIME stands for Multipurpose Internet Mail Extensions (MIME) which is an Internet standard that extends the format of e-mail to support text in character sets other than US-ASCII, non-text attachments, multi-part message bodies, and header information in non-ASCII character sets. Virtually all human-written Internet e-mail and a fairly large proportion of automated e-mail is transmitted via SMTP in MIME format.

MIME-Version: 1.0

The Content-class: is another MIME header, telling MIME-compliant mail programs what type of content to expect in the message.

Content-class: urn:content-classes:message

The X-MimeOLE: header information field lists the Information about originating client software. In this case it tells us that the e-mail was generated by Microsoft Exchange V6.5 which is Microsoft Exchange 2003 server.

X-MimeOLE: Produced By Microsoft Exchange V6.5

Another informative header is X-Server-Uuid:. The acronym Uuid stands for Universally Unique Identifier and it is a standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. In essence, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labeled with UUIDs can be later combined into a single database without need to resolve name conflicts. A UUID in this header is a 16-byte number and is listed in its canonical form a UUID.

X-Server-Uuid: 01D0514C-F675-407B-8466-C5A4562EB4EB

The Received: header contains a lot of very important information that you can use to draw some conclusions about the recipient’s network. You can also identify the IP address of the sender’s e-mail gateway and the type of encryption, if any, used by both domains. You can also identify the IP addresses of all servers involved during the e-mail communication. Therefore, this portion of the header is the most helpful when you debug TLS encryption. This information could also be used by hackers to penetrate your network.

In this example:

Received: from by sfs-mailgw01.test.com over TLS secured channel with ESMTP (SMTP Relay); Tue, 10 Oct 2006 13:03:30

we can see that the e-mail was received from an e-mail gateway with the IP address of by an e-mail gateway sfs-mailgw01.test.com and the e-mail was encrypted by TLS protocol and was relayed through secure channel. We can assume that sfs-mailgw01.test.com is a secure channel used to relay encrypted messages and it is a part of the firewall or sits between the firewall and the e-mail system and it must have SMTP Port 25 open for the encrypted traffic only.

This portion of the header of an e-mail that does not have TLS enabled looks a lot different and provides more information about its origin and destination.

Received: from by sfs-mailgw01.test.com with ESMTP
  (SMTP Relay); Wed, 11 Oct 2006 10:58:16 -0400
 X-Server-Uuid: E603B01C-6B0E-4E40-9394-2765A2997DB0
 Received: from exchange-1.Chi.my-test.com ([]) by
  exchange-1.Chi.my-test.com with Microsoft SMTPSVC(6.0.3790.1830); Wed,
  11 Oct 2006 09:57:58 -0500

In this case, we can see the full name of the sender’s e-mail server in active directory exchange-1.Chi.test.com its internal IP address, the global IP address of the sender’s SMTP server, the version of the SMTP virtual server 6.0.3790 and its UUID. All this information could help in breaching network security. The potential attacker can also draw a basic network diagram which would help him to navigate through your network. The Active Directory domain name for this domain is Chi.my-test.com. This is the root of the entire network that resides on Windows 2003 domain server. Essentially, this is the name of the domain to which he/she must authenticate with in order to gain access to its resources.

The last portion of the e-mail header:

Received: from SFS-EXGW01.firm.test.com ([]) by sfs-exmb02.firm.test.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Oct 2006 13:01:51 -0700
Received: from sfs-mailgw01.test.com ([]) by SFS-EXGW01.firm.test.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Oct 2006 13:01:51 -0700

That the e-mail gateway sfs-mailgw01.test.com with the global IP address passed the e-mail to an internal Microsoft Exchange server called SFS-EXGW01.firm.test.com. Based on the version of the SMTP server SMTPSVC(5.0.2195.6713), we can conclude that SFS-EXGW01.firm.test.com server is a Windows 2000 server which runs Microsoft Exchange 2000 server enterprise edition. It passed the e-mail message to sfs-exmb02.firm.test.com server, which according to the version of the virtual server is also a Microsoft Exchange 2000 server with the internal IP address of

Based on this information we could deduce that firm.test.com domain is configured with the front and backend Exchange servers and a secure e-mail gateway called sfs-mailgw01.test.com. We can also conclude that this e-mail gateway is not a Microsoft product since it drops the TLS ID number. The following is the portion of the header of the e-mail received from a domain that does not have third party e-mail gateway:

Microsoft Mail Internet Headers Version 2.0
 Received: from ny01.it.s-rom.com ([]) by nydev.it.s-rom.com with Microsoft SMTPSVC(5.0.2195.6713);
   Fri, 6 Oct 2006 14:40:13 -0400
 Received: from s-room.com ([]) by ny01.it.s-rom.com with Microsoft SMTPSVC(5.0.2195.6713);
   Fri, 6 Oct 2006 14:40:13 -0400
 Received: from
 by ny01.it.s-rom.com with ESMTP with TLS id 5202231.21867769;
  Fri, 06 Oct 2006 14:39:43 -0400
   Received: from exchange-1.Chi.my-test.com ([]) by
  exchange-1.Chi.my-test.com with Microsoft SMTPSVC(6.0.3790.1830);

As you can see, it lists the TLS id number that is generated randomly by the Microsoft Exchange Server.

We have been able to learn a lot about two domains just by deciphering a simple header message which contains a trove of very useful information that can be used both for debugging TLS protocol, e-mail problems as well as for hacking.

The e-mail header indicates whether the e-mail was encrypted, and as mentioned, the header of the test e-mail sent to a secure domain must include a TLS statement and the same TLS statement must be included in the returned e-mail that was sent from the secured e-mail. It is a confirmation that the TLS handshake occurred on both servers and the e-mails send to and from are encrypted.

< Previous story: How to configure TLS encryption on Microsoft Exchange 2003 serverWhat do I do if there is no TLS handshake? >

> Next story:

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2007 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)