使用Exchange 2003防御地址欺骗

　　垃圾邮件制造者常用的技术是配置电子邮件中的“发件人”一行，以隐藏发件人的身份。虽然 SMTP 不要求验证发件人的身份，但是 Exchange 2003 提供下列功能来帮助尽量减少地址欺骗：

　　默认身份验证设置

　　默认情况下，Exchange 2003 不解析发件人的电子邮件地址，除非发件人使用客户端程序(如 Outlook 或 Outlook Web Access)来通过 Exchange 服务器的身份验证。当 Exchange 收到来自已通过身份验证的客户端的邮件时，将验证发件人的姓名是否出现在全局地址列表 (GAL) 中，如果是，将在邮件中解析用户的显示名(在“发件人”一行)。如果未经过身份验证就提交原始邮件，Exchange 2003 会在起点就将该邮件标记为未经过身份验证，然后将该信息从一台服务器传输到另一台服务器。在这种情况下，发件人的地址不解析为 GAL 显示名(如 Ted Bremer)，而是以 SMTP 的格式显示给收件人(如 [email protected])。应提醒用户警惕这样一类邮件：这些邮件声称来自组织中的其他用户，但并未解析为 GAL 显示名。

　　但是，Exchange 2000 不解析匿名提交的邮件。为此，如果要从 Exchange 2000 升级，建议您在升级邮箱和其他 Exchange 服务器之前，先将网关服务器升级到 Exchange 2003.此外，如果要阻止 Exchange 2000 服务器解析匿名邮件，可以执行下列操作。

　　阻止 Exchange 2000 解析匿名电子邮件

　　警告 注册表编辑不当可能导致严重的问题，甚至可能需要重新安装操作系统。因注册表编辑不当而导致的问题可能没有办法解决。在编辑注册表之前，请备份所有重要数据。

　　1. 启动注册表编辑器 (regedit)。

　　2. 导航到注册表中的下列项，或者在注册表中创建这样一项(其中一个 1 表示 SMTP 虚拟服务器编号)：

　　HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/

　　MsExchangeTransport/Parameters/1

　　注意 可能需要同时创建 Parameters 项和 1 项。

　　在“编辑”菜单上，单击“添加值”，然后添加下列注册表值：

　　Value name： ResolveP2

　　Data type： REG_DWORD

　　使用下列标志来确定要使用的值：

　　Field Value

　　----------- -----

　　FROM： 2

　　TO： and CC： 16

　　REPLY TO： 32

　　要确定应使用的值，请针对要解析的所有元素添加相应的值。例如，要解析除发件人以外的所有字段，请键入 48 (16+32=48)。要仅解析收件人，应只键入 16.默认情况下，Exchange 2000 解析所有字段(可以通过删除该注册表项或者使用公式 2+16+32=50 设置该值来指定此行为)。

　　退出注册表编辑器。

　　重新启动 SMTP 虚拟服务器。

　　在选择要启用此设置的服务器时应小心。如果在默认 SMTP 虚拟服务器上更改此行为，并且组织中存在多个服务器，那么来自其他 Exchange 2000 服务器的所有内部邮件也会受影响。因此，由于 Exchange 2000 使用 SMTP 在服务器之间路由内部邮件，您可能要创建新的 SMTP 虚拟服务器，或者仅在传入方向上的 SMTP 桥头服务器上应用此设置。

　　跨目录林身份验证设置

　　如果组织包含多个目录林，那么可以在 SMTP 桥头服务器要求身份验证的目录林之间配置信任关系。

　　注意 工作流应用程序可以匿名提交邮件;因此，在组织中配置身份验证之前，应确保评估工作流应用程序的需求。

　　匿名访问设置

　　尽管 Exchange 2003 使客户端用户能够识别带有欺骗性的邮件，但仍应在所有内部 Exchange 服务器上关闭匿名 SMTP 访问功能。关闭匿名访问功能有助于确保只有已通过身份验证的用户能够在组织内部提交邮件。此外，要求身份验证会迫使使用 RPC over HTTP 的客户端程序(如 Outlook Express 和 Outlook)在发送邮件之前先通过身份验证。

　　反向域名系统查找

　　如果您直接从 Internet 上的其他域接收邮件，可以配置 SMTP 虚拟服务器对传入的电子邮件执行反向域名系统 (DNS) 查找。这样可以验证发件人邮件服务器的 Internet 协议 (IP) 地址和完全限定域名 (FQDN) 是否与邮件中列出的域名一致。但是，应考虑到 DNS 查找存在下列限制：

　　。 发件人的 IP 地址可能不存在于反向 DNS 查找记录中，或者，发送方服务器可能对于同一个 IP 有多个名称，并且不是所有的这些名称都存在于反向 DNS 查找记录中。

　　。 反向 DNS 查找加重了 Exchange 服务器的负担。

　　。 反向 DNS 查找要求 Exchange 服务器能够与发送域的反向查找区域联系。

　　。 对每个邮件执行反向 DNS 查找可能导致延迟增加，从而使性能大幅度下降。