这个问题让我很困惑。这个问题可能需要迁移到服务器故障，但是有一个编程组件，所以我想我会从那里开始。此外，我们的基础架构团队坚信一切都很好，但这并不总是意味着什么。
无论如何，我有一个简单的 GET-POST-Redirect 操作，它使用 Postal nuget 包发送两封单独的电子邮件，然后重定向到成功页面——非常基本的东西。该操作是异步的，我使用await email.SendAsync()的是 Postal API。
提交表单后，第一封电子邮件会立即进入我的收件箱，但代码会在该await email.SendAsync()行挂起 15-20 秒，然后再转到下一行（在调试器中确认）。然后，它开始发送第二封电子邮件，它再次立即进入我的收件箱，并且无论是否成功发送，代码都会再次挂在该行上，持续 15-20 秒，然后再转到带有重定向的行。在生产中，发送电子邮件后的这种延迟，结合两封电子邮件，会导致连接在重定向响应发送之前重置。当然，我可以只延长页面超时时间，但这并不能真正解决问题，因为用户在得到响应之前仍然会延迟一分钟。
我也尝试过使用 just 同步发送电子邮件email.Send()，但会发生相同的行为。我查看了 Postal 的源代码，虽然它围绕 SMTPClient 进行了一些自定义包装以发送异步电子邮件，但实际上除了使用同步Send方法发送标准的旧 C# 电子邮件之外别无他法。
它也没有绑定到运行站点的服务器，因为我可以在生产和本地调试中看到相同的行为（尽管都连接到同一个生产 Exchange 服务器）。
它的行为就像它在等待 Exchange 服务器发送某种“完成”响应，但根据我对 SMTP 的了解，它不是那样工作的。它应该只是将电子邮件发送到 SMTP 服务器并愉快地继续，相信 SMTP 服务器实际上会做它应该做的事情。
任何想法都将不胜感激，因为我什至不确定此时如何继续调试它。我还能测试或尝试什么？
更新
感谢@MichaelEvanchik 建议试用 Wireshark，我能够清楚地看到 Exchange 服务器实际上导致了 30 秒的延迟。它接收到要发送的电子邮件的最后一位，然后在 30 秒后最终以“成功排队等待发送”响应客户端。正是在这一点上，客户端最终退出并且代码恢复。所以，我把它踢回基础设施。
更新#2
因此，显然连接器实际上有 30 秒的延迟，以确认电子邮件已真正发送，而不仅仅是排队等待发送。就个人而言，我认为这首先违背了“排队等待交付”的观点，但无论如何，我不需要确认它实际上已发送，只需确认它已被 Exchange 服务器接收，因此基础设施正在移除延误。