Exchange传输组件大揭秘中Word格式.docx

Exchange传输组件大揭秘中Word格式.docx

《Exchange传输组件大揭秘中Word格式.docx》由会员分享，可在线阅读，更多相关《Exchange传输组件大揭秘中Word格式.docx（17页珍藏版）》请在冰豆网上搜索。

Exchange的传输层反病毒API与此事件相关联，用来实现邮件被传输之前的病毒检测和扫描。

我们也可使用CDO之类的编程技术，来开发自定义的EventSink与此事件相关联，CDO中的CDO_OnArrival事件实际上就是对OnTransportSubmission的包装，通过CDO_OnArrival事件可以得到实际被传输的邮件的句柄，对邮件进行特殊的操作。

具体可以参考微软知识库：

837851,“HowtoconfigureanInternetInformationServicesSMTPvirtualservertoarchiveortoremovemessagesinanExchangeServer2003testenvironment”

SMTPTransportOnCategorize

OnCategorize并不是一个单独的事件，而是当邮件被分拣处理时产生的一系列事件（共有十个单独的事件）。

与这个事件群相关联的EventSink我们称之为分类器（Categorizer），在Exchange2003中，共有两个分类器与OnCategorize事件群进行了关联，他们分别是ExchangeCategorizer（phatcat.dll）和OutlookMobileAccessPushCategorizer（miscat.dll）。

前者用于完成诸如收/发件人地址解析、DL分拆、收件人限制检查等等常规的分类器职责（这些职责则在下文会详细讨论），后者是用来完成为手机用户发送邮件到达提醒的特殊功能。

SMTPTransportOnGetMessageRouter

该事件在邮件被认为需要进行远程投递或者路由解析时被触发。

同OnCategorize一样，这也是一个事件群。

与此事件群相关联的EventSink是ExchangeRouter模块（会在下一期的连载中详细讨论）。

SMTPTransportOnMsgTrackLog

与此事件关联的是MessagingTracking日志记录组件，这个EventSink负责记录邮件投递过程中的日志，可以通过ExchangeSystemManager来启动此功能并且进行邮件投递的追踪。

（请参考微软知识库文档：

HowtoenablemessagetrackinginExchangeServer

SMTPTransportOnDnsResolveRecord

此事件在系统需要把一个目标域名解析为MX记录的IP地址时被触发，与此事件相关联的EventSink是ExchangeLoadBalancer。

该组件负责DNS解析并在有多个路由组连接器存在的情况下进行负载平衡。

SMTPStoreDriver

此事件在邮件需要被保存到硬盘或者数据库时被触发。

同OnCategorize一样，这也是一个事件群，这些事件与StoreDriver进行关联，当邮件需要被保存时，由StoreDriver负责执行对文件系统和数据库的读写操作（下一期的文章会对此事件群作深入的讨论）。

上面我们简单的列出了由AQE触发的事件，可以看出，其中的三个事件群（分别是OnCategorize、OnGetMessageRouter和StoreDriver）在邮件的投递过程中起着至关重要的作用，他们负责了激活相应的邮件的分类、路由和存储EventSink。

在进一步研究这些EventSink组件的工作内容时，我们再通过一张图来回顾一下由AQE触发的事件。

（图一）

图一：

由AQE触发的事件

在上文中我们提到，ExchangeServer传输组件内共有四种类型的事件，如果把上面提到的这些重要事件按照类别进行归类，我们可以发现其中大部分的事件属于SMTP传输事件。

在ExchangeTransport模块中，微软一共开发了6个EventSink来响应这些SMTP传输事件，他们的名字和作用如下表：

EventSink名称

作用

ExchangeTransportXEXCH50Submission

该EventSink响应OnSubmission事件，它的主要代码在Peexch50.dll中被实现。

这个EventSink的主要作用是处理ExchangeServer间的通信。

所有的服务器内部通信也是通过SMTP协议来完成的，他们使用XEXCH50这个微软自定义的命令字。

ExchangeTransportAntiVirusAPI

该EventSink响应OnSubmission事件，它的主要代码在OnSubmit.dll中被实现。

这个EventSink的主要作用是为反病毒厂商提供了一组在传输层的病毒扫描API，使用此API的程序可以在OnSubmission事件发生时截获邮件内容并进行病毒扫描。

通常情况之下，反病毒厂商更倾向于使用基于数据库层面的反病毒接口，因此这个传输层反病毒API默认是被禁用的。

如果服务器是邮件网关、前端服务器，管理员可以通过更改注册表的方式启用此接口。

ExchangeCategorizer

这是ExchangeServer最重要的模块之一，由在Phatcat.dll中实现的EventSink响应OnCategorize事件群中的事件。

Phatcat.dll中的代码实现了地址解析、邮件转发、设定外发邮件地址标识、展开DL、进行各类传输限制的检查等等至关重要的功能。

Categorizer中的代码同时也实现了邮件归档（journaling）和特殊情况下的邮件拆分（bifurcate）。

MobileCategorizer

Miscat.dll中的EventSink负责处理移动设备用户的邮件到达通知（up-to-datenotifications）。

这是Exchange2003中的新功能。

ExchangeRouter

这个EventSink由Reapi.dll中的代码实现，用来响应OnGetMessageRouter事件群中的事件。

AQE通过Reapi.dll来确定邮件的下一跳（nexthop）地址。

这个EventSink同时计算Exchange组织的路由拓扑和路由表。

ExchangeLoadBalancer

这个EventSink也是由Reapi.dll中的代码实现，它响应OnDnsResolveRecord事件，负责在多个外部连接器之间进行负载平衡。

表一：

响应SMTP传输事件的EventSink。

下文中，我们将重点讨论在ExchangeCategorizer中发生的故事。

OnCategorize事件群一共由十个事件组成，我们可以通过MSExchangeTransport的诊断日志来了解这些事件的细节，诊断日志的开启方法请看图二。

系统还允许管理员开启Level7级别（DebuggingLevel）的SMTP诊断日志来监控SMTP服务器的每一个动作，这个日志的开启需要进行注册表的更改，具体的键值位置请参考此文档：

HowtoenableSMTPprotocollogging

图二：

启动MSExchangeTransportDiagnosticsLogging

为了全面分析，我们先简单的把这10个Event和他们对应的EventSink的职能列出来：

（如表二）

OnCategorize事件

EventSink所执行的操作

Register

分类器组件初始化事件，负责创建分类器与其它模块（如活动目录访问、路由引擎等等）的连接

BeginMessageCategorization

表示邮件分类过程的开始

EndMessageCategorization

表示邮件分类过程的结束

BuildQuery

通过收发件人的proxyAddresses属性来创建对活动目录进行查询的LDAP语句，来获取收发件人对象的完整信息，这是地址解析的重要过程之一

BuildQueries

执行批量的BuildQuery操作

SendQuery

发送查询请求到活动目录，此查询是异步的

SortQueryResult

根据查询条件对返回的结构进行处理

ProcessItem

将地址解析的结果应用到邮件上

ExpandItem

这个过程也是邮件投递过程中非常重要的一环，DL分解、发送限制检查、邮件拆分都在这里发生

CompleteItem

当以上操作完成后，CompleteItem事件的EventSink执行邮件传送归档（Journaling）、组织内收件人的服务器定位以及其它的一些特殊操作

表二：

请参考微软知识库文档来了解Categorization过程更多的细节：

XCON:

WhatMessageCategorizationinExchange2000ServerInvolves

我们可以从表二中看到，OnCategorize事件群的EventSink执行了邮件投递过程中的很多重要操作，我们重点讨论其中三个EventSink的处理细节。

第一：

BuildQuery和地址解析

BuildQuery是一个非常复杂的过程，要完全理解这个组件，首先需要了解ExchangeServer中的各种“邮件地址类型”。

在ExchangeServer中，我们常用的SMTP地址（username@）只是种类繁多的邮件地址类型里面的冰山一角。

每一种邮件协议，都有它特定的邮件地址表示方法，LotusNotes、NovellGroupWise、古老的MSMail等等，都有一套特定的邮件地址，只不过相比SMTP，这些邮件地址类型我们很少接触到罢了。

Exchange中必须支持的其他邮件地址类型还有：

X.400address、Legacyexchangedn、Non-Exchangeaddress等等。

要说清楚这些地址类型，我们还需要从Exchange的发展史谈起。

Exchange5.5时代，微软为了兼容X.400和X.500协议，在邮件系统内部采用了X.400这样的用户邮件地址表示方式，随着Internet的发展，Exchange产品也开始把重心侧重到对SMTP协议的支持，从Exchange2000开始，SMTP成为了Exchange中邮件传输的主力协议，但是为了兼容Exchange5.5，微软仍然保留了MTA传输引擎和X.400地址类型，同时，在活动目录中引入了Legacyexchangedn这样的属性。

我们可以在Exchange管理器的Recipient->

RecipientPolicy->

DefaultPolicy->

属性->

E-mailaddress中看到当前的Exchange系统支持的地址类型。

默认支持的地址类型是SMTP和X.400（这两个类型不允许被删除）。

我们也可以添加诸如cc:

Mail、LoutsNotes、NovellGroupWise之类的地址类型，当ExchangeServer通过外部连接器和这些第三方的邮件系统连接时，这些地址就会发挥作用。

（此处不深入讨论）

我们重点看SMTP地址类型。

默认请况下，Exchange里面的SMTP地址类型中的SMTP域名和活动目录的域名是一致的，但是需要明确的是，此处的SMTP域和活动目录域是完全不同和没有丝毫关系的。

举例来说，我们可以在公司内网建立一个名为的AD域，然后在Internet上申请到一个my-的公网域名。

我们可以在RecipientPolicy中添加这个my-的域名，使Exchange系统意识到它有责任接收和处理发给my-的邮件（在公网DNS上设定my-的MX记录）。

并且，我们可以设定my-为主SMTP地址，这样所有外发到Internet的邮件，都会使用@my-作为其发信人地址。

如下图（图三）：

图三：

RecipientPolicy

关于RecipientPolicy中SMTP地址的设定和自定义，请参考下面的文章：

XIMS:

HowtoReceiveMessagesforTwoSMTPDomains

当在活动目录中创建用户时，如果我们细心观察就会发现，系统并没有让管理员输入用户的SMTP地址和X.400地址中的任何一种地址！

对于一个有邮箱的用户来说，他的邮件地址是ExchangeServer通过一个叫做RUS（RecipientUpdateService）的过程，根据RecipientPolicy中设定好的地址类型来自动生成的。

用户是活动目录中的对象，这些邮件地址，就是这个对象上的属性。

HowtheRecipientUpdateServiceappliesrecipientpolicies

当邮件分类器需要解析收件人邮件地址并进行投递时，它会根据邮件报文中的proxyAddresses字段来进行活动目录查询，以获取收件人在活动目录中的对象和其他的一些属性。

不同的发送协议（SMTP/MTA）和邮件客户端（MAPI/SMTP）会在信件写入不同的proxyAddresses，可能是SMTP地址，也可能是X.400或者Legacyexchangedn。

Exchange的BuildQuery过程会根据这些proxyAddresses生成一个LDAP的查询，比如，当邮件的收件人为mike@时，查询语句为：

（proxyAddresses=smtp:

mike@）。

如果活动目录中有这个用户，查询会返回对这个用户对象的引用和一系列进行邮件投递的必要属性，比如：

Homemdb、Homemta、msExchHomeServerName、msExchMailboxSecurityDescriptor、msExchMailboxGuid。

通过这些属性，Exchange传输系统就会知道这个用户的邮箱位置等信息。

查询单个用户是最简单的情况，在收件人是邮件组时，会涉及到各种不同类型邮件组地址格式处理和连接邮件组解析服务器等操作，情况会复杂很多。

简单来说，BuildQuery会配合其他的组件采用递归查询的方式解析收件人中的各个项目，直到所有的收件人都被查到为止。

BuildQuery过程也会查询发件人的信息，这是为了处理发件人限制、权限之类的情况。

BuildQuery只是万里长征的第一步，当结束了用户地址查询，并获取了用户对象的若干属性后，CAT引擎将进行更进一步的邮件处理。

第二：

ExpandItem和特殊邮件的处理

在ExpandItem阶段，传输引擎会执行预先定义的邮件发送限制、转发设置和进行邮件拆分，下面我们详细的看一下每一个过程。

Restrictionchecking

这个过程检查收件人和发件人是否有收发送邮件的权限和邮件尺寸方面的限制，举例来说，如果管理员在Exchange中设定不允许一封邮件中的收件人超过特定的数量，分类器会通过在BeginMessageCategorization的时候初始化一个计数器，并在解析收件人的时候用这个计数器计算这封邮件一共有多少个收件人。

如果超过了预先设定的数量，分类器就会通知AQE进入到退信流程：

AQE会产生错误代码为5.5.3的退信给发件人。

Alternaterecipients

我们可以在活动目录中设置把发给某人的邮件作自动转发（活动目录用户属性->

ExchangeGeneral->

DeliveryOptions）。

这个过程的具体实现就是在ExpandItem中完成的。

分类器会根据转发的设定，在收件人列表中（只在SMTP信封上添加，正文部分看不到转发地址）添加被转发的邮箱地址。

在到达最终目的地之前，邮件有时候需要在组织内的多台服务期间传递，为了避免转发地址被多次添加（每经过一台服务器，SMTP服务器都会执行分类器操作和转发检测），当第一次执行分类器操作并添加好转发地址以后，分类器会在邮件上做一个XEXCH50的标识，这样当下一个服务器看到此邮件时，就不会作重复的转发解析工作了。

同时，分类器也会检查潜在的转发循环情况（A转发给B，B转发给C，C又转发给A）。

如果循环被侦测到，分类器会通知AQE，后者即刻生成错误代码为5.4.6的退信给发件人。

Messagebifurcation（邮件分拆）

前面两个过程比较简单，现在我们讨论相对复杂得多的“Messagebifurcation”过程。

当发送一份邮件给若干个收件人时，在一些特殊情况下，每个收件人收到的信息内容和格式必须不相同，这时就需要通过bifurcation过程来制作邮件的副本。

读者可能无法理解为什么同一封邮件的收件人希望接收到不同格式和内容的邮件，我们举一个例子：

想象一下当一封信件被发给一个名为“StevenSun”的用户和“CompanyAllEmployee”邮件组这两个地址时，前者是一个普通的收件人，而后者是一个组，并且该组的成员是隐藏不可见的。

发信人设定了这封邮件的送达回执和阅读回执，但是因为收件人中有一个隐藏成员的组，Exchange必须采取某些措施来避免送达回执向发件人泄漏组中的成员。

Exchange采用bifurcation为此邮件制作两个副本，第一个副本是给StevenSun的，其中有正常的送达回执和阅读回执。

第二个副本是给CompanyAllEmployee的，这封信中，Exchange会去掉这些引起信息泄漏的回执请求。

这个过程对收信人是透明的，Bifurcation生成的两个副本，只是在其SMTP信封和正文的信头中，有不同的收件人和回执设定，所有的收件人在Outlook中读到的信件正文都是一样的（如果不理解，请回忆前一期文章中提到的SMTP报文格式）。

当发送密件抄送（BCC）和使用MAPI的客户端发信给Internet用户时，还会发生更加复杂的bifurcation的过程，限于篇幅，这里不错深入的讨论。

有兴趣的读者，可以参考如下的链接：

第三：

CompleteItem和路由、投递前的准备工作

经过一些列CategorizerEventSink处理后，邮件的目的地和收件人相应的属性都已经确定，在把邮件交给路由引擎选路和进行投递之前，Categorizer会做一些最后的收尾工作，并为路由和投递准备好需要的信息，这个过程包括：

邮件归档、写入收件人标示、投递状态结果的处理等等。

Journaling

邮件归档（Journaling）是把某个指定的邮箱数据库中的用户发送和接收的邮件做一个自动归档的过程（请参考：

XADM:

HowtoEnablethe"

MessageJournaling"

FunctionforanExchangeServerMailboxStore

正如前面提到的，是否归档是根据用户的邮箱所在数据库来决定的。

当一个用户通过SMTP网关发送邮件时，在这封邮件最终抵达收件人时，可能会被Exchange系统中的多台SMTP服务器进行处理和转发。

第一台SMTP服务器负责添加转发地址，并且，服务器使用XEXCH50命令来通知其他的后续服务器归档操作已完成，避免其他服务器重复的添加归档地址。

（XEXCH50命令在前文的邮件转发中也有类似的作用。

）

由于邮件归档是基于SMTP正文中的地址进行的（请再次参考上期文章中的SMTP报文结构一段），它有些时候对BCC、自动转发和邮件组来说可能会无效。

发给这些地址的邮件不一定会被自动的归档。

如果公司必须要做到100%的邮件跟踪和归档，可以采用基于SMTP信封的归档（EnvelopeJournaling）。

这个功能可以通过一个微软提供的名为E-MailJournalingAdvancedConfigurationTool的工具实现。

（请参考