在Exchange 2010中计划/排队大型电子邮件，直到延迟减少

我的挑战

我们在各个站点都有Exchange服务器，但在船上也有。在海上时，船只通过卫星链路连接到我们的网络，而在港口时，则切换到WiFi桥。

由于高延迟（500毫秒以上）和不常见的丢失（例如，当船转弯时），试图在海上发送超过几兆字节的任何电子邮件很可能会失败并重试直到限制已经达到。结果：电子邮件无法传递，每次尝试都会在卫星链接上消耗宝贵的带宽。

一种“解决方案”是将最大电子邮件大小限制为5 MB，但这几乎不方便用户使用，并且在端口传输过程中没有必要的限制。

粗略的想法

我希望做的是将所有大于设置限制的电子邮件排队，以便以后在海上发送时立即发送所有小型电子邮件。然后，我以为我应该定期对数据中心中的集线器传输服务器执行ping操作，当延迟下降到约400毫秒以下时，我将开始处理大型电子邮件队列。当等待时间超过400毫秒时，我会塞住漏洞，让电子邮件再次排队。

现在，自2003年以来，我还没有真正接触过Exchange。那时，您可以安排大型电子邮件以供以后发送，因此我的想法是在Exchange 2010中执行类似的操作，然后编写一种方法来切换发送在“始终”和“从不”之间安排大型电子邮件的时间表。

障碍

创建这样的脚本应该不会太复杂，但是随后我了解到，Exchange 2007已删除了我依赖的功能：

这是Exchange 2003中的一项功能，但已在Exchange 2007中删除。此功能是在SMTP连接器上设置的，“对超大邮件使用不同的传递时间”。

TechCenter：是否可以根据Exchange中的大小安排电子邮件传递？

问题

是真的吗 -该功能是否已不再存在于Exchange 2010中，或者仅已转变为类似功能，可以用来实现目标？如果是这样，该怎么办？

是否有另一种方法可以推迟在某些Exchange服务器上传送大型电子邮件？它可能基于时间表，甚至可能需要采取特定的行动-我相当确定会有某种方式可以通过脚本触发交付，我只需要在船上的单独队列中发送大量电子邮件即可。

您对此的想法将不胜感激！:-)

编辑1：精炼的粗略构想

我偶然发现了两个PowerShell CmdLets，我认为它们可以使我非常接近我的目标：

• Suspend-Message
• Resume-Message

我玩弄了Get-Message一段时间，以查看上面的命令将处理哪种消息。

最重要的是，这些命令接受消息大小过滤器。此命令将列出当前服务器上大于5 MB（5,242,880字节）的已排队消息：

get-message -Filter {Size -gt 5242880}

似乎Get-Message仅从各种远程传递队列返回邮件。但是，在服务器中流动的消息是否短暂而又出现在Get / Suspend / Resume-Message会混乱的队列中？

如果不是这样，则解决方案可能像每隔几分钟执行一次预定脚本一样简单，大致方法如下（使用伪代码）：

if ping_rtt > 400 Then
    Suspend-Message -Filter {Size -gt 5242880}
Else
    Resume-Message
EndIf

关注/后续问题：

现在大多无关紧要-参见编辑＃2。

将Get-Message只从远程传递队列返回邮件-不会从服务器内部传递消息吗？如果不是，那么远程传递队列的标识名称是否遵循可以用于过滤的特定模式？

是否可以/应该通过自定义传输代理（由@longneck建议）或事件接收器（如果此概念在Exchange 2010中仍然存在）来完成？

假设我每5分钟运行一次脚本，这仍然意味着发送大型邮件可能会导致长达5分钟的问题，然后才将其暂停。我们现在的状况仍然会比现在更好，但这并不是最佳选择。我可以将频率增加到每分钟，但这并不是最优雅的解决方案。

即使我每隔5分钟仅检查一次往返时间（以节省流量），每次提交远程传送的邮件时，也需要设置哪种Exchange机制才能检查上次记录的RTT排队，然后采取适当的措施？

编辑2：建议的解决方案

请允许我总结一下所提出的解决方案以及它们的优缺点：

海关运输代理

概念

• 定期监视延迟，分为高或低（阈值：400毫秒？）
• 通过自定义的传输代理，当延迟类别更改时，暂停/恢复所有大于设置阈值的电子邮件
• 如果延迟时间长，则通过自定义TA，立即将随后提交的大型邮件置于“挂起”模式

长处

• 延迟高时，永远不会尝试发送大型电子邮件

弱点

• 没有内部开发技能（自我说明：源代码应属于与外部开发人员签订的合同的一部分，属于我公司）
• 绑定到Exchange的第三方软件可能会在修补或更新时引起问题
• 如果出现问题，需要某种支持协议（请参见上文）

中度大邮件

概念

• 定期监视延迟，分为高或低（阈值：400毫秒？）
• 根据延迟分类，通过脚本配置Exchange传输规则，以使所有邮件都可以流动或将大邮件转发给主持人
• 在船舶进入港口时，可能由人工批准主持人队列中的消息

长处

• 延迟高时，永远不会尝试发送大型电子邮件
• 使用本地本地Exchange传输规则挂起邮件

弱点

• 从外观上看，当等待时间很短时，无法以编程方式批准消息，因此每次船舶进入港口时都需要人工干预
• 如果未通过编程方式处理审核，则可能存在隐私问题

问题

• 可以通过程序从主持人邮箱中批准邮件吗？怎么样？

计划的PowerShell命令

概念

• 定期监视延迟，分为高或低（阈值：400毫秒？）
• 只要延迟很高，就经常（每分钟？）暂停所有大消息（Suspend-Message -Filter {Size -gt 5242880}）
• 当延迟降低时，恢复所有消息（Resume-Message）

长处

• 实施起来很简单

弱点

• 不是最优雅的解决方案
• 只要Suspend-Message命令之间的间隔时间较长，就可以尝试传递每个新的大消息，这可能仍会浪费一些带宽并造成拥塞（尽管与不执行任何操作相比非常简短）

问题

• 关于如何防止在Suspend-Message命令之间传递大消息的尝试有什么想法？
• 将Get-Message只从远程传递队列返回邮件-不会从服务器内部传递消息吗？如果不是，那么远程传递队列的标识名称是否遵循可以用于过滤的特定模式？

编辑＃3：前进的道路

在团队中提出了建议的解决方案（包括SMTP代理之后，我没有将其包含在编辑＃2中）之后，根据我自己的直觉，我们决定选择自定义Exchange传输代理。

我正在与一些咨询公司联系，他们将就如何解决该问题以及如何解决问题向我回复。

如果您有外包编程任务的任何经验，请随时将有关我的相关问题的反馈留在Stack Overflow上，因为我没有。

为了解决您所要求的问题，您可以使用Microsoft Exchange Transport Agent SDK编写自己的Transport Agent 。传输代理是基于事件的，因此Exchange会在收到邮件时调用您库中的函数。然后，您的图书馆可以执行类似保留消息的操作。如果您没有内部执行此操作的技能，那么我敢肯定您可以聘请开发人员为您编写它。

但是我认为这不是一个很好的解决方案。作为调查的替代方法，您可能希望查看SMTP代理之类的低质量链接。正如您所发现的，SMTP是低质量链接的可怕协议，因为连接中断会导致邮件传输从头开始重新启动，而不是从中断处重新开始。如果您打算雇用开发人员来做某事，我会考虑编写一个服务器程序，该程序接受传入的SMTP连接，并将消息以可恢复的方式发送到附属连接另一端的同一程序的远程实例上（可能通过TCP端口将大消息与小消息分隔开，以允许WAN加速器进行QoS处理）。然后，远程实例可以在收到完整的消息后，

邮件审核

一种可能不理想的解决方案是使用传输规则将一定大小的邮件转发到发件人的经理或指定的邮箱（在船舶的Exchange服务器上）进行审核。这样，如果它们在海上，则大邮件实际上可以在另一个邮箱中排队。当船舶到达港口时，经理或指定的主持人可以批准他们进行交货。

缺点是：

• 除非您手动禁用此规则，否则它始终处于启用状态（但是可以通过脚本来完成），因此即使在端口较大的邮件中，该消息也会重定向到主持人邮箱
• 所有大型邮件都需要在发送之前由人工进行人工审核，但您可以在规则中为特定内容添加例外
• 另一个人正在阅读传出邮件，由于隐私问题，这可能不理想，但这取决于您的组织

一个好处是，您将由人为决定是否应发送一条消息，例如用户是否试图发送一堆与工作无关的废话，而这些废话只会无故中断连接。可以通过管理控制来纠正它们，例如指向策略并将其拍在手腕上，以便他们不再执行此操作。

Exchange 2010运输规则

自定义脚本

RE：用于管理大型电子邮件的自定义脚本。我可以看到类似下面的内容，它将在Exchange服务器上启用/禁用您的发送连接器。不利的一面是所有邮件都排在队列中，而不仅仅是大型邮件，但是遵循以下原则的一些逻辑应该起作用：

1. 检查延迟。如果该值较低，请启用发送连接器，取消任何大消息的暂停，然后等待5分钟（或其他任意时间长度）。如果它很高，请禁用发送连接器。
2. 等5分钟。
3. 5分钟后，检查是否有大消息并将其挂起。重新启用发送连接器，以便释放较小的已排队消息，直到队列为空（您甚至可以一次循环浏览1条消息，以便在重新启用发送连接器后不阻塞队列/ WAN链接）
4. 禁用发送连接器并转到＃1

不能完全理解这种逻辑，以100％地理解，但是您有个主意-将所有邮件排队，检查延迟，将大邮件挂起（如果邮件过多），取消排队，将所有邮件排队等。运行的另一个缺点像这样的脚本，如果它崩溃或停止，您如何知道在船上没有IT人员的情况下重新初始化它？它可能无限期地停止所有出站邮件（如果在禁用“发送连接器”后停止了），或者如果它只是使“发送连接器”处于启用状态并且脚本不再运行，则可能会丢失大型邮件控件。

SMTP代理

即使您已表示反对在Exchange之外进行任何邮件处理，但在考虑了一些其他问题后，我还是决定使用@longneck来使用某种类型的SMTP代理解决方案。甚至IIS SMTP都具有递延的传递机制，而Exchange 2010似乎没有。您可以将大型邮件重定向到IIS SMTP服务器，后者可以将它们存储在磁盘上，并在延迟低时首先检查延迟，让IIS SMTP服务器通过脚本发送它们。如果您的调度机制被卡住或停止，最坏的情况是大消息卡在磁盘上，但小消息继续发送。可能有比IIS SMTP更好的解决方案，我自己从未使用过它，但这只是一个例子。

在IIS 7中配置SMTP电子邮件

尝试看看Exchange 2010 SP1引入的“邮件限制”的新功能。这可能对您的用例很有帮助。

http://technet.microsoft.com/zh-cn/library/bb232205(v=exchg.141).aspx