客户正在使用 Outlook/Exchange 中的“延迟投递”功能。出于某种原因，此功能确实将原始邮件创建时间（即用户点击“发送”按钮的时间）保留为 RFC-822 Date: 标头，因此即使邮件的投递确实“延迟”，标头仍然带有证据表明该邮件是在投递前一段时间编写的。我的客户希望将 Date: 标头设置为邮件实际离开 Exchange 组织的时间，这样它看起来就像是最近编写和发送的。
解决此问题的方法是将所有传出的 SMTP 邮件上的日期：标头设置为 Exchange 2007 环境中服务器的当前时间。
我知道我可以设置一个 new-Transportrule，将 -Action 参数设置为 Microsoft.Exchange.MessagingPolicies.Rules.Tasks.SetHeaderAction，并定义用其他值替换“Date”。但是，我看不出有办法在其中使用 Get-Date 之类的函数的动态返回值 - Get-Date 的结果最多会转换为执行 new-Transportrule cmdlet 时所具有的静态值。
Lambda 表达式/闭包将执行所需的功能（即，不插入静态值而是插入函数指针并在每次运行时重新评估表达式），但据我所知，Powershell 不支持这些。
一个丑陋的解决方法是使用更新的当前时间非常频繁地重新定义（例如每分钟一次）传输规则，但如果有更优雅的解决方案，我想避免这种情况。
对此有什么想法吗？
编辑 简单解释一下为什么使用这个功能：客户希望发送包含决策结果的邮件，该结果在某个日期之前不能公开。此外，他还希望隐藏决策的日期/时间，以避免不必要的讨论。
这是实际上是 MUA 的一个功能（Outlook 开箱即用），但服务器支持当然是一个额外的好处，因为即使客户端未运行，邮件也会被发送。还有一个问题：MUA 在将消息传输到服务器时设置“日期：”标头，而服务器在从等待队列中释放时不会更改它。过去Outlook 中两个功能类似的功能- 一个叫做“延迟交付”，一个叫做“延迟提交”。显然，后者才是这里所需要的，但它已在 Outlook 2000 中被删除，并且从未重新引入 - 可能是因为 Outlook 团队试图向 Apple 学习。
答案1
将 Outlook 客户端设置为连接后不立即发送。他们撰写邮件并像平常一样点击发送。邮件位于发件箱中。当他们“真正”想要发送邮件时，只需从发件箱中打开邮件并再次点击发送，它将重新为邮件添加时间戳。然后在 Outlook 中执行发送/接收。在标题中看不到原始撰写日期/时间的证据。或者（可能是一个更好的解决方案），只需撰写邮件并将其保存在草稿中，然后在您真正想要发送时发送它...
我知道这不是您描述的解决方案，您希望在服务器级别全局处理所有消息，而更像是客户端的解决方法。如果有很多这样的消息需要这样做，那就很烦人了，但每周/每月几条消息对他们来说还不算太糟。客户端的奇怪要求......“发送消息，但不要真正发送消息，直到我允许......”如果您不想发送消息，请不要点击发送按钮......
另一种可能性是甚至不使用 Outlook 发送邮件，在记事本中撰写邮件，将其保存为受支持格式的 eml 文件，然后编写脚本将其放入捡起文件夹在适当的日期/时间发送到 Exchange 服务器上进行传送。
答案2
我知道这并没有回答你的问题。我也不指望有人赞成，但没有人反对。
延迟交付是一个设计错误的功能。它让人们免于思考。他们可以点击“发送”，然后思考并说“哦，我想撤销‘发送’”。但应该是“思考”，然后“发送”或“取消”。同样的问题也出现在“回收站”问题上。有人发明了这个糟糕的功能，现在你随处可见。人们不再思考。先删除，然后思考为什么删除是一个错误。目前每个人都在抱怨为什么没有回收站来处理所有事情。（嫁给某人然后问撤销按钮在哪里）。
但该功能还带来了另一个心理问题。如今，每个人都认为电子邮件是一种即时通讯媒介（但事实并非如此！）。点击发送按钮时，邮件应该到达收件人。对于大多数邮件来说，这都是事实，至少在几秒钟内，因此任何导致延迟的事情都是不便的。客户端的延迟交付和收件人的灰名单都带来了这样的不便。
我不知道有哪个邮件服务器包含这个开箱即用的功能。可能是因为没有必要。在我看来，这是不是MTA 的一部分。这应该是 MUA 的工作。在将（新创建的）邮件传送到中继主机之前，客户端应该提供一个确认对话框：“您真的要发送这封邮件吗？请在点击‘是’之前检查一下。[是] [[否]]”甚至可能带有验证码。
说到这一点，您应该考虑修改 Outlook 而不是 Exchange 来做到这一点。
答案3
我现在无法测试这一点，但我记得在我工作过的最后一个地方，我们运行的是 Exchange 2007 和 Outlook 2010。我们实际上遇到了另一个相关问题，因为使用缓存模式的 Outlook 的笔记本电脑的用户使用了此功能，除非客户端正在运行并连接到 VPN 或在办公室，否则不会传递消息。我们追踪到，如果客户端在缓存模式下运行，则行为类似于延迟提交；消息位于客户端的发件箱中，而不是服务器中。结果是客户端必须打开才能在适当的时间提交，时间戳是提交时间。
如果我没记错的话，并且该行为没有改变，那么这可能会有效。