测试和Microsoft Exchange 2003服务器上调试TLS协议

六部分的文章的第5部分：测试加密最简单的方法是将电子邮件发送到您刚刚配置的域的电子邮件管理员，请他/她送你回了E-的头邮件。

第六部分的第五部分:

1. 配置和故障排除TLS在Exchange Server
2. 什么是传输层安全协议？
3. TLS协议是如何工作的
4. 如何在microsoftexchange2003服务器上配置TLS加密
5. 在microsoftexchange2003服务器上测试和调试TLS协议
6. 如果没有TLS握手，我该怎么办?

测试加密最简单的方法是向您刚才配置的域的电子邮件管理员发送电子邮件，并请他将电子邮件的头部发回给您。标题将列出消息从您的SMTP服务器传输到另一个服务器的路径，以及它是否经过TLS加密。电子邮件标题还可以告诉您许多关于收件人网络和电子邮件服务器的性质的信息。了解如何读取标头是一项必要的故障排除技能。

现在让我们检查下面的标题，看看我们可以从中学到什么:

点击查看(弹出)

头基本上显示该电子邮件消息从发送者到接收者如何行进。但是，还装载了可在故障排除过程中使用其他非常有用的信息。关于消息的起源的信息总是在头部的底部。首先，它会显示时间，当这条消息是原来的到达时间：

x -原始到达时间:2006年10月10日20:01:51.0389 (UTC) FILETIME=[ED237CD0:01C6ECA6]

当您试图调试用户报告的电子邮件问题时，这些信息可能很有用，而且各种调查人员也可能发现这些信息很有用。下一个字段是“返回路径”

返回路径：admin@my-test.com

这告诉您非交付报告(NDR)发送到何处。因此，如果用户说他从未收到NDR，您就知道到哪里去查找。

内容类型：

内容类型：多部分/替代;边界= “----_ = _ NextPart_001_01C6ECA6.E3E1952E”

是另一个MIME头，它告诉符合MIME规范的邮件程序在消息中期望看到什么类型的内容。

X-WSS-ID是Windows服务器系统ID的首字母缩写:

X-WSS-ID: 693523182 p810969-01-01

在本例中，我们可以说发送方从Windows 2003服务器发送了此消息。约定是X-报头是非标准的，只提供信息，相反，任何非标准的信息报头都应该以“X-”开头。这一惯例经常被违反。

标有“X”的下一个信息标题是X-TMWD-垃圾邮件摘要。缩写代表坦布尔韦德通信公司的报头的功能这部分作为垃圾邮件标记和在这种情况下，电子邮件没有标记为通过标签CAT = 0垃圾;CON = 0。这也告诉我们收件人使用Tumbleweed公司为电子邮件网关。

X-TMWD-Spam-Summary: TS = 20061010200333;塞夫= 2.0.2;回转体= A2006101008;
IFV = 2.0.4, 4.0 8;RPD = 4.00.0004;ENG = IBF;RPDID = 303030312 e30413031303230372e34353242464245332
E303031342D452D53446B4565396F2B417A52344D4934777341474569673D3D;猫=没有;反对=没有

然后就可以得到发送和接收邮件的人的电子邮件地址。

自： “系统管理员”到： “E-mail.admin”

线程索引和线程主题用于多个邮件，以类似的线程关联。例如，在Outlook中的会话视图会使用这些信息来找到一个对话线程的消息。

Thread-Index: Acbsnlxw + / PzW9SmRguHZSLpvjClIwAAQFjwAAF / =

线程主题:另一个测试包捕获

后面两个标记为“X”的信息性标头是:X- ms - tnef - correlator和X- ms - has - attach。

X-MS-Has-Attach:

X-MS-TNEF-Correlator:

在MS-TNEF是代表传输中性封装格式，由Microsoft Exchange和发送格式为RTF格式（RTF）消息时，Outlook电子邮件客户端使用专有格式的缩写。Microsoft Exchange时认为它是将消息发送到另一Microsoft电子邮件客户端它提取所有格式信息并以特殊的TNEF块对其进行编码。然后它发送两个部分消息 - 与格式化除去格式化在TNEF块指令的文本消息。在接收侧，微软电子邮件客户端处理TNEF块和重新格式化该消息。

不幸的是，大多数非微软电子邮件客户端不能破译TNEF块。因此，当您接收到带有非microsoft电子邮件客户机的TNEF编码的消息时，TNEF部分会以一长串十六进制数字的形式出现在消息本身中，或者作为附加文件(通常名为WINMAIL.DAT)出现。

在X-MS-HAS-附：通知该客户端准备发送的附件，它也通知的电子邮件是否包含任何附件。如果电子邮件包含附件的信息头X-MS-HAS-附：会说“是”冒号后面。

X-MS-Has-Attach:是的

In-Reply-to:和消息ID:的意思本质上是一样的。两个电子邮件服务器都为电子邮件提供了这个号码，以便进行识别。这些身份证号永远跟随着信息。您可以将它们复制并粘贴到消息跟踪中心以了解有关它们的更多信息。在对电子邮件路由和所有类型的取证进行故障排除时，这些信息非常有用。

消息ID：<E0F93F027183B144B62595406230ACA10220A1DD@mail.my-test.com>回答:<E316CF6728FBB74EBCEEF14D1640171A03EFB639@sfs-exmb02.firm.test.com>

日期和主题字段不言自明。然而，值得注意的是，电子邮件的发送日期和时间是基于发件人的计算机上的计算机时钟。

主题：RE：另一个测试数据包捕获

日期:2006年10月10日星期二15:01:35 -0500

的MIME-版本：1.0指定MIME协议的是使用由发送方的版本。缩写MIME表示多用途Internet邮件扩展（MIME），这是一个扩展的电子邮件格式的字符支持文本的因特网标准比US-ASCII，非文本附件，多部分邮件正文和标题设置等在非ASCII字符集的信息。几乎所有的人编写的Internet电子邮件和自动化电子邮件相当大的比例是通过在MIME格式的SMTP传输。

MIME-版本：1.0

content -class:是另一个MIME头，它告诉符合MIME规范的邮件程序在消息中需要什么类型的内容。

内容类:urn: content:消息

标题信息字段列出了有关原始客户端软件的信息。在本例中，它告诉我们电子邮件是由Microsoft Exchange V6.5生成的，它是Microsoft Exchange 2003服务器。

X-MimeOLE：生产由Microsoft Exchange V6.5

另一个信息标题是X-Server的UUID：。缩写UUID表示通用唯一标识符，它是软件工程中使用的标准，由开放软件基金会（OSF）的分布式计算环境（DCE）的一部分标准化。这样做的目的的UUID是使分布式系统唯一标识信息，而不显著中央协调。从本质上说，任何人都可以创建一个UUID并用它来确定合理的信心，标识将永远不会被无意地使用任何人任何别的东西。标有UUID的信息可以在以后合并为而不需要解决名称冲突的单一数据库。甲UUID在此标头是一个16字节的数，并在其规范形式一个UUID被列出。

X-Server-Uuid: 01 d0514c f675 - 407 b - 8466 c5a4562eb4eb

header包含许多非常重要的信息，您可以使用这些信息得出关于收件人网络的一些结论。您还可以标识发送者的电子邮件网关的IP地址和两个域使用的加密类型(如果有的话)。您还可以标识电子邮件通信期间涉及的所有服务器的IP地址。因此，在调试TLS加密时，头的这一部分最有帮助。这些信息也可以被黑客用来渗透你的网络。

在这个例子中:

收到:从216.20.31.164由sfs-mailgw01.test.com通过TLS有ESMTP (SMTP中继)的安全通道;2006年10月10日星期二13:03:30 -0700

我们可以看到，该邮件是通过邮件网关sfs-mailgw01.test.com从IP地址为216.20.31.164的邮件网关接收到的，该邮件通过TLS协议加密，通过安全通道转发。我们可以假设sfs-mailgw01.test.com是一个用于中继加密消息的安全通道，它是防火墙的一部分，或者位于防火墙和电子邮件系统之间，它必须为加密通信打开SMTP端口25。

不具有TLS的电子邮件的标题的这个部分启用看起来非常不同，并提供有关其出发地和目的地的详细信息。

收到:从216.20.31.164由sfs-mailgw01.test.com与ESMTP (SMTP继电器);收到:来自exchange . chi.my-test.com([192.168.16.121])的exchange . chi.my-test.com与Microsoft SMTPSVC(6.0.3790.1830);2006年10月11日星期三09:57:58 -0500

在这种情况下,我们可以看到发送者的电子邮件服务器的全名在active directory交换- 1. chi.test.com 192.168.16.121其内部IP地址,发送方的SMTP服务器的全球IP地址216.20.31.164,SMTP虚拟服务器的版本6.0.3790及其UUID。所有这些信息都有助于破坏网络安全。潜在的攻击者还可以绘制一个基本的网络图，以帮助他在您的网络中导航。此域的Active Directory域名为Chi.my-test.com。这是驻留在Windows 2003域服务器上的整个网络的根。从本质上说，这是他/她必须使用的域的名称进行身份验证，以获得对其资源的访问权。

电子邮件头的最后一部分:

Received: from SFS-EXGW01.firm.test.com ([10.48.1.75]) by sfs-exmb02.firm.test.com with Microsoft SMTPSVC(5.0.2195.6713);2006年10月10日星期二13:01:51 -0700

Received: from sfs-mailgw01.test.com ([216.9.22.168]) by SFS-EXGW01.firm.test.com with Microsoft SMTPSVC(5.0.2195.6713);2006年10月10日星期二13:01:51 -0700

全球IP地址为216.9.22.168的电子邮件网关sfs-mailgw01.test.com将电子邮件传递到名为SFS-EXGW01.firm.test.com的Microsoft Exchange内部服务器。基于SMTP服务器SMTPSVC(5.0.2195.6713)的版本，可以得出SFS-EXGW01.firm.test.com服务器是运行Microsoft Exchange 2000 server enterprise edition的Windows 2000服务器。它将电子邮件消息传递到sfs-exmb02.firm.test.com服务器，根据虚拟服务器的版本，该服务器也是Microsoft Exchange 2000服务器，内部IP地址为10.48.1.75。

根据这些信息，我们可以推断出firm.test.com域配置了前端和后端交换服务器以及一个名为sfs-mailgw01.test.com的安全电子邮件网关。我们还可以得出结论，该电子邮件网关不是微软产品，因为它删除了TLS ID号。以下是来自没有第三方电子邮件网关的域的电子邮件头的部分:

Microsoft邮件Internet邮件头版本2.0收稿日期：从ny01.it.s-rom.com（[10.10.150.30]）由nydev.it.s-rom.com与Microsoft SMTPSVC（5.0.2195.6713）;周五，2006年10月6日14时40分13秒-0400收稿日期：从s-room.com（[207.13.0.13]）由ny01.it.s-rom.com与Microsoft SMTPSVC（5.0.2195.6713）;周五，2006年10月6日14点四十零分13秒-0400收稿日期：从216.20.31.164

通过ny01.it.s-rom.com与ESMTP与TLS ID 5202231.21867769;周五，2006年10月06日14时39分43秒-0400收稿日期：从exchange-1.Chi.my-test.com（[192.168.16.121]）由exchange-1.Chi.my-test.com与Microsoft SMTPSVC（6.0.3790.1830）;

正如你所看到的，它列出了由Microsoft Exchange服务器随机生成的TLS ID号。

通过破译一个简单的头信息，我们已经了解了两个域的很多信息，其中包含了非常有用的信息，这些信息可以用于调试TLS协议、电子邮件问题以及黑客攻击。

电子邮件头指示电子邮件是否加密，如前所述，发送到安全域的测试电子邮件头必须包含一个TLS语句，从安全电子邮件发送的返回电子邮件中必须包含相同的TLS语句。这确认了TLS握手在两台服务器上都发生了，发送和发送的电子邮件都被加密了。

<以前的故事:如何在microsoftexchange2003服务器上配置TLS加密如果没有TLS握手，我该怎么办?>

>接下来的故事：