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