为通过身份验证连接和匿名连接配置 smtp_exchange server

文档定义

关于 IT 的“注释”是 Microsoft IT 从技术角度对特定主题的简短深入探讨，通常都与现有的 IT Showcase 文档相关。“注释”可能逐步说明 Microsoft IT 如何执行一项特定的操作任务，或者如何配置某硬件设备或软件应用程序。它还可能叙述某个最佳实践的详细内容或包含有关 Microsoft IT 的操作方面经常请求的信息。

目标读者

Microsoft Exchange Server 2003 管理员

产品与技术

· Exchange Server 2003

· SMTP

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

为减少管理开销，Microsoft 信息技术 (Microsoft IT) 小组需要更改 Microsoft%26reg; Exchange Server 2003 进行内部简单邮件传输协议 (SMTP) 连接的方式。Microsoft IT 将 SmtpIpRestrictionFlag 属性设置为 1 来配置 SMTP 虚拟服务器，以允许来自明确的 IP 地址列表的匿名连接，但也允许来自其他 Exchange 服务器的所有通过身份验证的连接。

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

导言

许多消息传递环境使用内部网关服务器来路由源自各种源的消息。这些源可能包括本地电子邮件环境中的服务器、电子邮件环境之外的应用程序服务器以及来自其他电子邮件环境的服务器。当环境使用多种技术时，允许匿名连接往往很有必要，因为所有主机之间的身份验证并非总是可能的或可行的。虽然存在这样的选择只是允许所有匿名连接，但这样将创建一个未托管的环境。反之，管理多个被允许连接的列表可能会导致不必要的管理开销。

Microsoft IT 将其 Exchange 基础结构中的 SMTP 传输视为宝贵资源，因此该小组在对该基础结构的访问方面进行了控制和管理。在某些情况下，Microsoft IT 需要允许某些特定的 SMTP 客户端进行匿名连接，但仍允许来自所有通过身份验证的客户端的连接。

在使用 Microsoft Exchange 2000 Server 的环境中，即便将某个单一 Internet 协议 (IP) 地址添加到了 SMTP 虚拟服务器上的允许连接列表中，也无法连接任何其他客户端（匿名的或通过身份验证的）。对于要连接的通过身份验证的客户端（例如，其他 Exchange 服务器），必须将其 IP 地址添加到允许连接列表中。在企业环境中，这样做可能要涉及几十个甚至数百个 IP 地址。由于进行的更改未被共享（这些更改都是在每台虚拟服务器上分别配置），因此，如果有多台 SMTP 虚拟服务器，则问题就复杂了。

Microsoft IT 想确保只有经过授权的实体（例如，Exchange 服务器或特定的 SMTP 客户端）才可将电子邮件直接提交给该小组的内部 Exchange 传输，如图 1 所示。

图 1. Microsoft IT 中的 SMTP 需求拓扑结构图

在努力为 SMTP 路由环境提供安全性而又不产生大量管理开销的过程中，Microsoft IT 需要更改其 SMTP 虚拟服务器的行为。Microsoft IT 所实施的更改可使 SMTP 虚拟服务器允许来自明确的 IP 地址列表的匿名连接，但也允许来自其他 Exchange 服务器的所有通过身份验证的连接。

本文档专为 Exchange 管理员而准备。其假定读者已掌握了 Microsoft Windows Server 2003、Microsoft Exchange Server 2003 SMTP 以及路由概念和各种系统工具方面的应用知识。除了涉及完成各任务所必需的步骤之外，本文档并未在其中全面介绍任何系统工具方面的详细信息。

注意：出于安全原因，本文档样例中使用的林状结构名称、域名、内部资源名称、组织名称以及内部开发的应用程序和文件的名称，并不代表 Microsoft 内部使用的真实名称，它们仅供说明之用。此外，本文档中内容主要描述 Microsoft IT 运行企业数据中心的方式。本文档中的步骤和过程并非有关如何运行通用数据中心的规定性指导，而且可能不受“Microsoft 客户支持服务”的支持。

背景信息

Microsoft IT 在其 Active Directory%26reg; 目录服务结构中支持多个林状结构。大多数 Microsoft 员工使用主要的公司网络林状结构。产品用户则使用许多较小的林状结构。

某些情况下，Microsoft IT 需要允许来自有限数量的电子邮件客户端的匿名连接，但也要允许所有通过身份验证的连接，而不考虑其源 IP 地址。支持此行为可满足单个服务器对灵活性的需要，使其既可用作林状结构间的集线器，又可用作林状结构内部的集线器，因而不会产生过多的管理开销。

例如，Microsoft IT 将 MSFT-HUB-xx 服务器用作由 Microsoft IT 托管的各种林状结构间的 SMTP 桥头和网间路由组集线器。在设法为路由环境提供安全性的过程中，如果 Microsoft IT 将指定的 SMTP 桥头服务器（位于非主要的公司网络林状结构中）的 IP 地址添加到允许连接列表中，则只有这些服务器才可以进行连接。在主要的林状结构中的 Exchange 服务器不能连接到 MSFT-HUB-xx 服务器，除非其 IP 地址也被添加到该列表中。因此，维护此列表将需要大量的管理开销。因为对于主要的公司网络林状结构中的 Exchange 服务器，通过其身份验证状态就可知道它们已经是受信任的实体，所以再将它们添加到允许连接列表中是多此一举。

两个现有的配置设置允许到 SMTP 虚拟服务器的连接，如表 1 所示。

表 1. 允许两种类型 SMTP 连接的原始设置

连接控制设置	行为
All except the list below（以下列表除外）（默认）	除非表中列出的 IP 地址，否则所有客户端均可连接到 SMTP 虚拟服务器。
Only the list below（仅以下列表）	只有表中列出其 IP 地址的客户端才可连接到 SMTP 虚拟服务器。

注意：客户端可能会连接到 SMTP 虚拟服务器，但客户端是否能够将电子邮件提交到服务器则取决于其他设置，例如，支持的域和支持的身份验证方法。

图 2 所示的流程图说明了在建立连接并提交消息后，SMTP 虚拟服务器所使用的逻辑。

图 2 中说明的默认行为没有利用组织中通过身份验证的 Exchange 服务器的 SMTP 状态，并且没有授予那些通过身份验证的 Exchange 服务器将电子邮件提交到受保护的 SMTP 虚拟服务器的功能。

更改的行为

作为一种解决方案，Microsoft IT 所做的配置更改允许将 SMTP 虚拟服务器配置为仅将 IP 限制应用于匿名连接。这些限制并不影响服务器的连接和身份验证。

因为连接建立之后就会进行身份验证，所以配置更改就会改变 SMTP 虚拟服务器的基础行为。最初会允许所有连接；然而，如果客户端的 IP 地址不在列表中，且客户端在尝试 mail from 命令前未通过身份验证，则将结束连接并产生一个 5.7.3 SMTP 响应（“Client was not authenticated（客户端未通过身份验证）”）。

Microsoft IT 通过修改服务器（此服务器以受保护的 SMTP 虚拟服务器的方式运行）上的 Microsoft Internet Information Services (IIS) 版本 6.0 元数据库参数来实现配置更改。通过创建元数据库项 SmtpIpRestrictionFlag=1，Microsoft IT 修改此行为以允许到 SMTP 虚拟服务器的连接，如表 2 所示。

表 2. 修改后的设置允许来自特定 IP 地址的通过身份验证的 SMTP 连接和匿名的 SMTP 连接

连接控制设置	行为
Only the list below（仅以下列表）	满足以下条件的所有 SMTP 服务器均可连接： · 如果连接通过身份验证，则客户端可提交消息*。 · 如果连接未通过身份验证，但客户端在允许的 IP 地址列表中，则客户端也可提交消息* · 否则，客户端将收到 SMTP 错误响应“5.7.3 Client was not authenticated（5.7.3 客户端未通过身份验证）”。

* 允许消息提交并不能保证可成功接收消息。提交的消息可能遇到其他的限制和过滤。

图 3 说明了表 2 中引用的连接控制设置。例如，在下列情况下，来自主机 10.168.0.1 的匿名 SMTP 连接和通过身份验证的 SMTP 连接将被接受。

图 3. 指定允许连接的 IP 地址

设置此标志仅影响被允许尝试提交电子邮件的客户端。此设置并不改变 SMTP 虚拟服务器有关处理匿名中继（相对于通过身份验证的中继而言）的行为。例如，通过匿名连接方式进行的提交仍然遵守 Sender Display Name Resolution（发送端显示名称解析）、Sender ID（发送端 ID）、Sender/Recipient Filtering（发送端/接收端过滤）和 Exchange Intelligent Message Filter（Exchange 智能消息筛选器）设置；它们不能跳过这些功能。

图 4 所示的流程图说明了在建立连接并提交消息后，SMTP 虚拟服务器所使用的逻辑。

图 4. 经修改的 SMTP 连接工作流方法

实施

实施更改分以下两步：

1. 在 IIS 元数据库中为 SmtpIpRestrictionFlag 属性创建一个新记录。

2. 设置其属性值。

默认情况下，元数据库中不存在 SmtpIpRestrictionFlag 属性。然而，管理员可使用 IIS Metabase Explorer 创建一个新记录并更改其属性值。IIS Metabase Explorer 是 IIS 6.0 Resource Kit Tools 集合的一部分，它可从 http://www.microsoft.com/downloads/details.aspx?FamilyID=56FC92EE-A71A-4C73-B628-ADE629C89499%26amp;displaylang=en 下载安装。IIS Metabase Explorer 的用户界面 (UI) 与 Microsoft Windows%26reg; Explorer 的 UI 类似。

要创建记录并设置其值：

1. 打开 IIS Metabase Explorer 并将其连接到要做更改的服务器。

2. 浏览到要做更改的 SMTP 虚拟服务器的容器。

3. 在 Edit（编辑）菜单上，指向 New（新建），然后单击 DWORD Record（双字节记录）。

4. 在 New Record（新记录）对话框中的 Record Name or Identifier（记录名称或标识符）列表中，选择 SmtpIpRestrictionFlag，如图 5 所示。

图 5. IIS Metabase Explorer 中的 New Record 对话框

注意：图 5 中列出的 Owner Key（所有者项）中的数字 1 表示 SMTP 虚拟服务器的编号。

5. 单击 OK（确定）保存新记录。

6. 双击此新记录打开其属性。

SmtpIpRestrictionFlag 属性可能有两个值：

· 0：启用通过身份验证的或受信任的 IP 地址连接（原始行为）。进行连接的服务器必须在 IP 列表中，而不管身份验证如何。

· 1：启用来自 Connection Control（连接控制）设置中所列出的 IP 地址的通过身份验证的连接和匿名连接。

7. 将其属性值更改为 1（如图 6 所示），然后保存更改。

图 6. 更改 IIS Metabase Explorer 中 SmtpIpRestrictionFlag 属性的值

除了在“允许连接列表”中列出的连接外，现在 SMTP 服务器还允许那些通过身份验证的连接。

更多信息

有关 Microsoft 产品或服务的更多信息，请拨打 Microsoft 销售信息中心的电话：[phone]。在加拿大，请拨打 Microsoft 加拿大信息中心的电话：[phone]。在美国 50 个州和加拿大以外的国家和地区，请联系当地的 Microsoft 子公司。要通过万维网获得信息，请访问：

http://www.microsoft.com

http://www.microsoft.com/itshowcase

http://www.microsoft.com/technet/itshowcase

本文档所包含的信息代表 Microsoft Corporation 在发布时对所讨论的问题的当前观点。因为 Microsoft 必须紧跟瞬息万变的市场形势，所以不应认为这是 Microsoft 的承诺，并且 Microsoft 无法保证发布日期之后信息的准确性。

本文档仅用于提供信息之目的。MICROSOFT 对于本文档中的信息不做任何明示、暗示或法定的保持。

遵守所有适用版权法是用户的职责。Microsoft 准许您对本文档的全部或部分进行复制，特别是完全出于自学的目的。

Microsoft 可能拥有涉及本文档中主题的专利、专有应用程序、商标、版权或其他知识产权。除非得到 Microsoft 明确提供的任何书面许可协议，否则本文并未向您做出对这些专利、商标、版权或其他知识产权的任何授权。

除非另行说明，否则在此描述的示例公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件纯属虚构的，与真实的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件没有任何联系，也不应推断出任何关联性。

%26copy; 2005 Microsoft Corporation。保留所有权利。

本文档仅用于提供信息之目的。MICROSOFT 在本摘要中未作任何明示或暗示担保。Microsoft、Active Directory、Windows 和 Windows Server 是 Microsoft Corporation 在美国和/或其他国家或地区的注册商标或商标。本文稿提及的真实公司和产品名称可能是其相应所有者的商标。