通过MAPI读取Exchange服务器时间
我想计算 Exchange 邮箱中邮件的期限，以确保它们在我们的程序（C++、MAPI）处理它们之前至少在那里停留一分钟。 这样，我们使用的垃圾邮件过滤器应该有足够的时间来完成其工作。
因为我们的程序运行的PC上的时间可能与Exchange服务器使用的时间不同，所以我们的程序必须通过MAPI读取服务器时间。
有一个优雅的解决方案吗？ 我能想到的一种方法是修改某些 Item 并立即读取其 PR_LAST_MODIFICATION_TIME ，但我想避免这种情况。
编辑：
我们的程序是一个批处理作业，每 10 分钟运行一次并读取日志邮箱。
I'd like to calculate the age of the messages in an Exchange mailbox to make sure they sit there for at least a minute before our program (C++, MAPI) processes them. This way the spam filter we use should have enough time to do its job.
Because the time on the PC where our program runs might be different from the time used by the Exchange server, our program has to read the server time via MAPI.
Is there an elegant solution to it? One way I can think of is to modify some Item and immediately read its PR_LAST_MODIFICATION_TIME, but I'd like to avoid that.
Edit:
Our program is a batch job that runs every 10 minutes and reads the journal mailbox.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用
PR_MESSAGE_DELIVERY_TIME。根据 MSDN：
除此之外 - 当您的解决方案无论如何在客户端上运行时 - 为什么不首先使用客户端时间？ 无论时钟是否正确，对于相对时间（例如“......之后一分钟”），这应该没有什么区别。
You can use
PR_MESSAGE_DELIVERY_TIME.As per MSDN:
Other than that - when your solution runs on the client anyway - why not use the client time in the first place? Incorrect clock or not, for relative times (e.g. "one minute after ...") this should make no difference.
我假设当邮件到达 Exchange 邮箱时您会收到 MAPI 事件通知。 我建议将这些消息推送到队列中并等待 n 秒（例如 60 秒），然后再处理消息。 由于时间与通知事件相关，因此计算机之间的时钟漂移不会出现问题。
在启动应用程序时，您将被迫再次对现有消息执行此操作，但我不认为这会造成问题。
I presume you are getting a MAPI event notification when the message arrives in the Exchange mailbox. I would suggest pushing these messages into a queue and waiting
nseconds (e.g. 60s) before processing the message. Since the time is relative to the notification event there will be no issue with respect to clock drift between the computers.On start up of your application you would be forced to do this for existing messages again but I would not imagine that this would pose an issue.