この問題は私を困惑させました。この質問は Server Fault に移行する必要があるかもしれませんが、プログラミング コンポーネントがあるので、そこから始めることにしました。また、私たちのインフラストラクチャ チームは、自分たちの側ではすべてがうまくいっていると熱心に信じていますが、それが常に意味を持つとは限りません。
とにかく、成功ページにリダイレクトする前に、Postal nuget パッケージを使用して 2 つの別々の電子メールを送信する単純な GET-POST-Redirect アクションがあります。これはかなり基本的なものです。アクションは非同期でawait email.SendAsync()、Postal API から使用しています。
フォームが送信されると、最初の電子メールがすぐに受信トレイに届きますが、コードawait email.SendAsync()は次の行に移動する前に 15 ～ 20 秒間、その行でハングします (デバッガーで確認)。次に、2 番目の電子メールを送信します。この電子メールはすぐに受信トレイに届き、送信が成功したかどうかに関係なく、リダイレクトのある行に移動する前に、コードがその行で 15 ～ 20 秒間ハングします。本番環境では、電子メール送信後のこの遅延が 2 つの電子メールを合わせて、リダイレクト応答が送信される前に接続がリセットされます。確かに、ページのタイムアウトを増やすことはできますが、それでもユーザーが応答を受け取るまでに 1 分間の長い遅延が発生するため、問題は実際には解決されません。
と同期してメールを送信しようとしましemail.Send()たが、同じ動作が発生します。Postal のソースを調べたところ、非同期メールを送信するために SMTPClient の周りにいくつかのカスタム ラッピングが行われていますが、同期Sendメソッドを使用した標準の古い C# メール送信以外には事実上何もありません。
また、サイトが実行されているサーバーにバインドされていません。本番環境とローカルでデバッグするときの両方で同じ動作が見られるためです (ただし、両方とも同じ本番 Exchange サーバーに接続しています)。
Exchange サーバーが何らかの「完了」応答を送信するのを待っているように動作しますが、SMTP について知っている限り、そのようには機能しません。電子メールを SMTP サーバーに送信するだけで、SMTP サーバーが本来の処理を実際に実行することを信頼して、陽気に作業を続行する必要があります。
この時点でこれをデバッグし続ける方法がわからないので、どんなアイデアでも大歓迎です。他に何をテストまたは試すことができますか?
アップデート
Wireshark を試すという @MichaelEvanchik の提案のおかげで、実際には Exchange サーバーが原因で 30 秒の遅延が発生していることを明確に確認できました。送信する電子メールの最後のビットを受信し、30 秒後に最終的にクライアントに「配信のキューに入れられました」と応答します。この時点で、クライアントは最終的に QUIT し、コードが再開されます。だから、私はそれをインフラストラクチャに戻しています。
更新 #2
そのため、実際にはコネクタに 30 秒の遅延が発生し、電子メールが配信待ちのキューに入れられただけでなく、実際に送信されたことを確認できるようになったようです。個人的には、そういうのはそもそも「配信待ち」という点を打ち負かしていると思いますが、とにかく、実際に送信されたという確認は必要なく、Exchangeサーバーによって受信されただけなので、インフラストラクチャは削除されています遅延。