我们在各个站点都有Exchange服务器，还有船上的服务器。 在海上时，船舶通过卫星链路连接到我们的networking，但在港口时切换到WiFi网桥。
由于高等待时间（500 + ms）和非常见的中断（例如船只转弯时），试图在海上发送几兆字节以上的电子邮件很可能会失败并重试，直到极限已经达到。 结果：电子邮件没有得到传递，每次尝试都会在sat链接上消耗宝贵的带宽。
一个“解决scheme”是将最大电子邮件大小限制为5MB，但这不是用户友好的，并且在端口上是不必要的限制。
我宁愿做的事情是将所有大于设定限制的电子邮件排队，以便在海上稍后交付时，立即发送所有小型电子邮件。 当时我正在考虑定期在数据中心对集线器传输服务器进行ping操作，当延迟低于400毫秒时，我开始处理大型邮件队列。 当延迟时间超过400毫秒，我会堵塞漏洞，让电子邮件再次排队。
现在，从2003年以来，我还没有对Exchange执行过真正的操作。当时，您可以安排大量的电子邮件以便稍后交付，所以我的想法是在Exchange 2010中做类似的事情，然后使用脚本来切换交付安排“永远”和“永不”之间的大邮件。
创build一个这样的脚本不应该太复杂，但是随后我发现，使用Exchange 2007删除了我所依赖的function：
这是Exchange 2003中的一个function，但是在Exchange 2007中删除了它。它在SMTP连接器上设置为“对于超大尺寸的邮件使用不同的传送时间”。
TechCenter：是否可以根据Exchange中的大小安排电子邮件传送？
这是真的吗？ – 此function在Exchange 2010中不再存在，还是仅仅转换为类似的东西，我可以用来实现我的目标？ 如果是这样，什么？
是否有另一种方法推迟在某些Exchange服务器上传送大型电子邮件？ 它可以基于一个时间表，甚至可能需要采取具体行动 – 我相当肯定会有一些方法来通过脚本来触发交付，我只需要在船上的一个单独的队列中的大型电子邮件。
您的想法将不胜感激！ 🙂
我瘫痪了两个PowerShell CmdLets，我认为可以使我非常接近我的目标：
Suspend-Message Resume-Message 我玩了一会儿Get-Message，看看上面的命令会处理什么样的消息。
最重要的是，这些命令接受一个消息大小filter。 此命令将列出大于5 MB（5,242,880字节）的当前服务器上排队的消息：
get-message -Filter {Size -gt 5242880}
看来Get-Message只会返回来自各种远程传送队列的消息。 但是，服务器内部的消息是否会短暂地出现在Get / Suspend / Resume-Message将被混淆的队列中？
如果不是这样，那么解决scheme可以像每隔几分钟一个简单的脚本一样简单（沿着伪代码）：
if ping_rtt > 400 Then Suspend-Message -Filter {Size -gt 5242880} Else Resume-Message EndIf
关注/后续问题：
现在大部分是无关紧要的 – 请参阅编辑＃2。
Get-Message将仅从远程传递队列返回消息 – 从不消息传递给服务器内部？ 如果没有，远程传送队列的身份名称是否遵循一定的模式，我可以用于过滤？
可以/应该通过自定义传输代理（如@ longneckbuild议）或事件接收器（如果这个概念在Exchange 2010中仍然存在）来完成？
假设我每5分钟运行一次脚本，这仍然意味着发送大量消息，可能会导致长达5分钟的问题，然后才会被暂停。 我们现在仍然比现在好，但并不是最佳的。 我可以把频率提高到每一分钟，但这不是最优雅的解决scheme。
即使我每5分钟只检查一次往返时间（以节省stream量），为了检查最后录制的RTT，我需要设置什么Exchange机制，每次提交一个消息到远程交付排队，然后采取适当的行动？
请允许我总结提出的解决scheme，以及我看到的利弊：
自定义传输代理
概念
优势
弱点
中等大消息
概念
优势
弱点
问题
计划的PowerShell命令
概念
Suspend-Message -Filter {Size -gt 5242880} ） Resume-Message ） 优势
弱点
Suspend-Message命令之间的间隔可能仍然会浪费一些新的大消息，可能仍然会浪费一些带宽并产生拥塞（尽pipe与没有做任何事情相比很短暂） 问题
Suspend-Message命令？ Get-Message将仅从远程传递队列返回消息 – 从不消息传递给服务器内部？ 如果没有，远程传送队列的身份名称是否遵循一定的模式，我可以用于过滤？ 在我的团队（包括SMTP代理，我没有包含在编辑＃2中）提出解决scheme之后，根据我自己的直觉，我们决定使用自定义的Exchange传输代理。
我正在和一些咨询公司联系，他们会告诉我如何解决这个问题，以及它会花费多less钱。
如果你有任何外包编程任务的经验，请随时留下我的相关问题堆栈溢出 ，因为我没有。
要按照您请求的方式解决问题，可以使用Microsoft Exchange Transport Agent SDK编写自己的传输代理。 传输代理是基于事件的，所以Exchange在收到消息时会调用库中的函数。 然后你的图书馆可以做一些事情，如保持消息。 如果你没有这方面的技能，我相信你可以聘请一个开发人员为你写。
但我不认为这是一个很好的解决scheme。 作为您进行调查的替代方法，您可能希望查找类似SMTP代理的内容以获取低质量链接。 正如你所发现的，对于低质量的链接，SMTP是一个可怕的协议，因为中断的连接会导致消息传输从头开始重新启动，而不是从停止的地方恢复。 如果你打算聘请一个开发人员做某些事情，我会考虑编写一个服务器程序来接受传入的SMTP连接，并以可恢复的方式将消息发送到卫星连接另一端的同一程序的远程实例可能通过TCP端口将大消息从小消息中分离出来，以允许WAN加速器进行QoS处理）。 然后远程实例可以在收到完整的消息后通过SMTP完成消息的传送。
信息审核
一个可能不理想的解决scheme是使用传输规则将邮件以特定的大小转发给发件人的pipe理员或指定的邮箱（在Exchange服务器上）进行审核。 这样，如果他们在海上，大邮件可以在另一个邮箱中排队。 船舶抵达港口时，经理或指定的主持人可以批准交付。
缺点是：
有一个好处是，你会有一个人决定是否应该发送一个消息，比如用户是否试图发送一堆非工作相关的垃圾，而这些垃圾只是无缘无故地连接在一起。 他们可以通过行政控制来纠正，比如指向一个政策，把它们放在手腕上，这样他们就不会再这样做了。
Exchange 2010传输规则
自定义脚本
RE：用于pipe理大型电子邮件的自定义脚本。 我可以看到类似于下面这样的启用/禁用Exchange服务器上的发送连接器。 不利的一面是所有的邮件都被保存在队列中，而不是大量的邮件，但是沿着这些线的一些逻辑应该可以工作：
这个逻辑并没有被完全抛光，以达到100％的意义，但你的想法 – 排队所有的邮件，检查延迟，挂起大邮件，如果它高，邮件排队，邮件排队等。运行的另一个缺点像这样的脚本是如果它崩溃或停止，你怎么知道没有IT人员在船上重新初始化？ 它可能会无限期地停止所有出站邮件（如果在禁用发送连接器之后停止），或者如果只启用发送连接器并且脚本不再运行，则可能会丢失大型邮件控制。
SMTP代理
即使你已经表示你反对在Exchange以外的任何消息处理，在考虑了这个之后，我已经决定使用某种types的SMTP代理解决scheme了@longneck。 即使IIS SMTP也有一个延期交付机制，看起来Exchange 2010并没有。 您可以将大量邮件redirect到可以将它们存储在磁盘上的IIS SMTP服务器，并首先检查延迟时间，让IIS SMTP服务器在延迟较低时通过脚本发送它们。 如果您的调度机制卡住或停止的最糟糕的情况是大的消息卡在磁盘上，但小的消息继续发送。 有可能比IIS SMTP更好的解决scheme，我从来没有使用它，但它只是一个例子。
在IIS 7中configurationSMTP电子邮件
尝试查看Exchange 2010 SP1中引入的“消息限制”的新function。 这可能对您的使用情况非常有帮助。
http://technet.microsoft.com/en-us/library/bb232205(v=exchg.141).aspx