了解收件人限制

适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上一次修改主题： 2010-02-01

您可以对组织中的收件人配置限制。通过这些限制，您可以按照符合组织策略的方式使用收件人。

要查找与管理邮箱服务器相关的管理任务吗？请参阅管理邮箱服务器。

目录

邮件大小限制

邮件传递限制

每封邮件的最大收件人数限制

邮箱大小限制

公用文件大小限制

邮件大小限制

邮件大小限制是在任何邮件系统中最常用的限制。设置最大邮件大小可防止您的邮件系统或基本网络基础结构过载。

根据要执行的任务，您可以为多个组件配置邮件大小限制。例如，您可以限制邮件的总大小，也可以限制各邮件组件（如邮件头、附件和收件人数目）的大小。

虽然还可以指定是将邮件大小限制应用到整个 Microsoft Exchange Server 2010 组织、应用到特定的连接器，还是应用到用户对象，但本节仅重点介绍可应用于收件人的邮件大小限制。有关可在 Exchange 2010 组织中配置的邮件大小限制的完整列表，请参阅了解邮件大小限制。

在为各收件人配置邮件大小限制时，请务必考虑组织中可能存在的其他邮件大小限制。例如，假设已将组织中的集线器传输服务器配置为限制邮件大小为 10 MB。在这种情况下，对于具有外部地址的邮件联系人，应将最大接收大小设置为不大于 10 MB。虽然组织中的发件人能够向此邮件联系人提交大于 10 MB 的邮件，但集线器传输服务器将拒绝接收该邮件。有关不同的邮件大小限制之间如何相互影响以及其优先级顺序的详细信息，请参阅了解邮件大小限制。

适用于所有收件人类型的邮件大小限制

Exchange 2010 可以向所有收件人发送或路由邮件。因此，可以为 Exchange 组织内的所有收件人类型设置最大接收邮件大小限制。如果发件人尝试发送大于指定大小的邮件，则该邮件会连同一封描述错误的邮件一起返回到此发件人。

在 Exchange 管理控制台 (EMC) 中，使用收件人属性中的“邮件流设置”选项卡来设置最大接收邮件大小。在 Exchange 命令行管理程序中，可以使用相应的 Set- cmdlet 中的 MaxReceiveSize 参数。有关如何为收件人配置接收邮件大小限制的示例，请参阅配置邮箱或已启用邮件的公用文件夹的邮件大小限制。

特定于邮箱和已启用邮件的公用文件夹的邮件大小限制

只有邮箱和已启用邮件的公用文件夹是可以向 Exchange 邮件系统提交邮件的收件人类型。因此，除了可以设置接收邮件大小限制外，还可以设置发送邮件大小限制。

在 EMC 中，使用邮箱属性中的“邮件流设置”选项卡可设置邮箱的最大发送邮件大小。在命令行管理程序中，使用 Set-Mailbox 和 Set-MailPublicFolder cmdlet 的 MaxSendSize 参数。有关如何为邮箱和已启用邮件的公用文件夹配置发送邮件大小限制的示例，请参阅配置邮箱或已启用邮件的公用文件夹的邮件大小限制。

重要说明：
如果要为邮箱用户实现发送邮件大小限制，还应确保已将客户端访问服务器配置为，可以接受等于或大于配置的发送邮件大小限制的客户端请求。Microsoft Office Outlook Web App 使用 ASP.NET，因此会受 ASP.NET 配置的影响。ASP.NET 具有 maxRequestLength 设置，该设置用于确定 Web 浏览器可以提交给客户端访问服务器的最大数据量。如果此限制低于发送邮件大小限制，则用户可能会收到一个感到困惑的错误。有关在 Outlook Web App 中管理最大邮件大小的详细信息，请参阅为 Outlook Web App 配置最大邮件大小。

公用文件夹管理控制台

公用文件夹管理控制台是一个基于 Microsoft 管理控制台 (MMC) 3.0 的界面，为 Exchange 管理员提供用于创建、配置和管理公用文件夹的图形用户界面 (GUI)。通过在公用文件夹管理控制台中使用公用文件夹属性的“邮件流设置”选项卡中的“邮件大小限制”选项，您还可以为已启用邮件的公用文件夹配置邮件大小限制。有关公用文件夹管理控制台的详细信息，请参阅使用公用文件夹管理控制台。

返回顶部

邮件传递限制

通过 Exchange 2010，您可以限制向各收件人传递邮件的方式。邮件传递限制适用于所有的收件人类型，可用于控制对 Exchange 2010 组织中特定收件人的访问。例如，多个组织可指定只有一小组用户可以向大型通讯组发送邮件。

可以对收件人配置下列邮件传递限制：

• 接受来自特定发件人列表的邮件   如果指定了接受其邮件的发件人列表，则收件人只能接收来自这些发件人的邮件。默认情况下，所有收件人都配置为接收来自所有发件人的邮件。

  对于希望只有少数授权发件人能够向其发送邮件的收件人，可以使用此限制。例如，您可能希望对包含组织内所有员工的通讯组进行配置，使其仅接受来自人力资源部门中负责公司内部通信的特定员工的邮件。再举一例，在零售组织中，可对代表供应商的邮件联系人使用此限制。您可能希望将其中的每个邮件联系人都配置为仅接受来自直接与那些供应商打交道的买主的邮件。

• 拒绝来自特定发件人列表的邮件   如果指定了拒绝其邮件的发件人列表，则收件人将拒绝来自这些发件人的邮件。默认情况下，所有收件人都不会配置为拒绝来自任何发件人的邮件。

  注意：
  此限制优先于“接收来自特定发件人列表的邮件”限制。如果某个发件人同时位于这两个列表中，则该发件人发送的所有邮件都将被拒绝。

  使用此限制可以阻止特定用户向特定收件人发送邮件。有关此限制的用途的示例，请看以下案例。您创建了一个名为“All Employees”的通讯组，并将该通讯组配置为仅接受来自属于“Human Resources”通讯组成员的发件人的邮件。但“Human Resources”通讯组中还包含实习生的邮箱，而您又不希望允许访实习生访问“All Employees”通讯组。因此，若要阻止实习生邮箱向“All Employees”通讯组发送邮件，您可以在为“All Employees”组配置“拒绝来自特定发件人列表的邮件”限制时指定实习生邮箱。

• 要求所有发件人均通过身份验证   如果将某个收件人配置为要求所有发件人均通过身份验证，则系统将拒绝组织中不具备有效登录凭据的发件人的所有邮件。默认情况下，只有新通讯组和动态通讯组配置为要求所有发件人均通过身份验证。

  注意：
  在以前的 Exchange 版本中，默认情况下，不会将收件人配置为要求所有发件人均通过身份验证。因此，从以前的 Exchange 版本中迁移过来的任意通讯组都不会配置此限制。

  使用此限制可以指定收件人仅接收来自已成功通过身份验证的内部发件人的邮件。例如，若要防止将来自 Exchange 组织外部的邮件传递到用于内部通信的通讯组，可以将这些组配置为要求发件人身份验证。

有关如何为收件人配置邮件传递限制的详细信息，请参阅配置邮件传递限制。

返回顶部

每封邮件的最大收件人数限制

集线器传输服务器路由要发送给许多收件人的邮件会花费相当多的时间。因此，这可能会影响集线器传输服务器的性能，进而影响 Exchange 组织中的总体邮件传递。

为了消除这种风险，可以对每封邮件允许的收件人数加以限制。虽然可以在邮箱级别上配置此限制，但也可以在较高的级别上配置此限制，如组织级别、连接器级别（仅限于接收连接器）以及集线器传输服务器级别。通常，最佳做法是在较高级别上配置此设置，而仅对异常情况使用邮箱级别配置。有关可配置此限制的各个级别的详细信息以及默认值列表，请参阅了解邮件大小限制。

有关如何为邮箱配置每封邮件的最大收件人数限制的详细信息，请参阅限制每封邮件的收件人数。

返回顶部

邮箱大小限制

可以为邮箱配置存储配额。通过使用存储配额，可以控制邮箱的大小并管理邮箱数据库的增长。有关如何配置邮箱存储配额的详细步骤，请参阅配置邮箱的存储配额。

注意：
还可以在邮箱数据库级别配置存储配额。为邮箱数据库配置的配额适用于该数据库中的所有邮箱，除非该邮箱配置为不使用邮箱数据库的默认设置。通常，最佳做法是在邮箱数据库级别配置存储配额，邮箱级别配置仅应用于异常情况。有关如何为邮箱数据库配置存储配额的详细步骤，请参阅配置邮箱数据库属性。

因为存储配额会直接影响存储容量规划，所以必须仔细规划存储配额。规划部署时，应考虑的因素是存储配额、每个邮箱数据库的邮箱数以及承载每个邮箱数据库的存储子系统。

在 Exchange 组织中部署统一消息 (UM) 前，必须查看所有已配置的现有存储配额。因为每个语音邮件都附加了 Windows Media 音频 (WMA) 文件和 Waveform 音频 (.wav) 文件，所以语音邮件可能要比电子邮件大。因此，语音邮件超出其配额的速度可能会比不包含附件的电子邮件快。有关统一消息对存储配额的影响的详细信息，请参阅了解存储配额和语音邮件。

返回顶部

公用文件大小限制

与邮箱类似，您也可以为已启用邮件的公用文件夹配置存储配额。通过使用存储配额，您可以控制已启用邮件的公用文件夹的大小，管理公用文件夹数据库的增长。

除了存储配额外，还可以为公用文件夹定义期限限制。如果为某个公用文件夹指定了期限限制，则此公用文件夹中所有超过此期限限制而未进行修改的项目都将自动从该公用文件夹中删除。这就为管理者控制其公用文件夹数据库的增长提供了另外一种选择。有关如何为公用文件夹配置存储配额和期限限制的详细步骤，请参阅配置公用文件夹属性。

注意：
存储配额和期限限制也适用于未启用邮件的公用文件夹。

返回顶部

 © 2010 Microsoft Corporation。保留所有权利。