我们目前有一个准备迁移到O365的On Prem Exchange服务器。
我们的组织有一个非常定制的邮件流系统，传入的电子邮件会到达我们的Edge服务器（我们的MX记录指向该服务器），然后每封电子邮件都要经过由.Net编写的4个SMTP事件接收器链。每个SMTP事件接收器都有一个非常特定的业务目的。最后一个SMTP事件接收器将带有智能主机的电子邮件路由到我们的On Prem Exchange服务器。
例如，最重要的接收器是根据主题中的模式重定向传入的电子邮件；每个电子邮件主题均经过测试，其中包含我们当前有效订单中的订单号（复杂的字母数字字符串）；如果找到，则将“收件人：”字段修改为发送给该订单的所有者，而与原始收件人无关。通过将电子邮件的主题传递到我们的本地数据库（MSSQL）中的存储过程来完成此过程，该数据库检查该电子邮件的主题中是否存在我们的任何有效订单号。
当我们将Exchange服务器移植到O365时，挑战就来了。通过在O365中创建传入连接器，我们能够保持相同的邮件流，并将智能主机配置更改为指向O365。
[我们现在面临的挑战是摆脱我们的本地SMTP事件接收器，并在Office 365（Exchange Online）上将相同的功能替换为“ something”。
主要挑战是，我基本上需要先“拦截”电子邮件，然后才能将其发送到原始收件人的收件箱，因此我有机会重定向它。
[我们正在考虑以下几种方法：1）使用O365的PUSH通知来通知我们已收到电子邮件，然后使用Outlook REST API修改电子邮件的收件人。这种技术的问题在于，通知不是即时的，仅在电子邮件到达收件箱时才发生。我想将电子邮件重定向到收件箱。
2）使用MS FLOW路由电子邮件。 FLOW将在我们的场所定期调用REST API以获取要检查的最新模式列表（订单号），然后FLOW将使用此列表进行适当的重定向。这是一个可行的选择，但据我了解，它需要支付额外费用（或迫使我们使用更昂贵的O365许可证来使用MS FLOW）
3）在Azure或AWS可能的服务器中重现我们当前的SMTP事件接收器。这会起作用，但是由于SMTP事件接收器是一种已过时的技术，并且在IIS 7中不受支持，因此我们正在尝试摆脱此技术。
最终的目的是让我们的整个邮件从我们的本地邮件中流出，因此即使我们的总公司断电（或在不时发生的Prem Exchange崩溃中，电子邮件也仍然可以流出；]）
我认为有第四个选择。可以使用所谓的传输代理（与Exhange 2007/2010/2013/2016/2019兼容）来代替事件接收器。这项技术并不落伍。我建议您在云中设置将运行自定义传输代理的Exchange服务器。
关于，维克多