SMTPメールのタイムアウトの問題

Question

Webアプリケーション用のユーザーを作成すると、SMTPメール（ASP.NETのSMTPCLIENTを使用）が自動的に生成されたパスワードを使用してユーザーに送信されます。ただし、タイムアウトになり、新しいユーザーがパスワードが記載された電子メールを受信しないことがあります。

それでは、メールは送信されなかったがユーザーは作成されたことを示すメッセージを表示します。

したがって、システム管理者にはこれまでのところ 2 つの選択肢があります。

1. ユーザーのパスワードをリセットし、自動生成されたパスワードを使用して別の SMTP メールが送信されることを期待します。
2. ユーザーを削除して再作成します。

smtp が送信されない場合、ユーザーの作成をロールバックできますが、この問題に対処するベスト プラクティスは何ですか?

タイムアウト期間を 5 秒ずつにして 3 回電子メールの送信を再試行する必要があると考えています。したがって、15 秒は最悪のシナリオになります。

これでいいでしょうか？

Answer 1

そうですね、プラットフォームによっては、メールをローカル MTA に引き渡すことができれば、再試行などは MTA が処理してくれるはずです。プログラムはメールをキューに入れて続行するだけでよく、タイムアウトやグレーリストなどの処理について心配する必要はありません。

それでもメッセージを配信できない場合は、いつでも (パスワード リセット機能を使用して) 再送信を試みることができます。それでも失敗する場合は、電子メール アドレスに間違いがある可能性が高いため、アカウントを削除してユーザーを再登録させることをお勧めします。

もちろん、これは、未確認のユーザーに対して何ができるかによっては、一部のシステムでは不可能な場合があります。それは、電子メールが検証される前にユーザーに何を許可するかによって決まります。

Answer 2

Web アプリが SMTP をユーザーのメール サーバーに直接通信しているようです。あなたのWebアプリは、ユーザーのMTA（メール転送エージェント）と話すMUA（メールユーザーエージェント）です。]ユーザーのMTAが現時点で到達可能または動作している必要があるとは言われていません。誰かがキューイングや再試行などを提供していることを確認するには、独自の MTA を実行する必要があります。

本当に後ろに曲がりたい場合は、現在行っていることを実行し (ただし、試行は 1 回のみ)、メッセージをキューにフォールバックし、少なくとも 24 時間は遅いスケジュールで再試行を続け、その未完了の状態をユーザーに公開することもできます。ユーザー。

アプリがどのように動作するかについての公式の答えは、次の場所にあります。 RFC1123 (インターネットホストの要件 - アプリケーションとサポート):

5.3.1.1 送信戦略

Sender-SMTPの一般的なモデルは、定期的に発信メールを送信しようとする1つ以上のプロセスです。典型的なシステムでは、メッセージを構成するプログラムには、新しい発信メールに即座に注意を要求する方法がありますが、すぐに送信できないメールは、送信者が定期的に再試行する必要があります。メールキューエントリには、メッセージ自体だけでなく、封筒情報も含まれます。

送信者は、1回の試行が失敗した後、特定の目的地の再試行を遅らせる必要があります。一般に、再試行間隔は少なくとも30分でなければなりません。ただし、送信者SMTPが非配信の理由を決定できる場合、より洗練された可変戦略は有益です。

メッセージが送信されるか、送信者がgiveめられるまで継続します。通常、あきらめの時間は少なくとも4〜5日である必要があります。Retryアルゴリズムのパラメーターは構成可能でなければなりません。

Answer 3

ASP.NET および System.Net.Mail クラスを使用している場合は、おそらく Web サーバー マシン上の IIS インスタンスを介してメールを送信していると思われます (指定していないのでわかりません)。メール転送エージェント (IIS SMTP) で何が起こっているかを知る良い方法はありません。独自の再試行ロジックがあり、デフォルトではメッセージが配信されるまでに長い時間がかかる可能性があります。

メールが配信されていないことをどのようにして検出しますか?「タイムアウト」は何から来ているのでしょうか？

メールの送信を処理するバックグラウンド プロセスが必要です。MTA への配信が成功した場合は、すべて問題がないと考えてください。スパムのブラックリストに登録されていない限り、ほとんどの MTA は成功するまで再試行を続けます。MTA でメッセージをドロップするときに実際にエラーが発生した場合は、必ず再試行するか、失敗の原因を特定してバグを修正してください。正直なところ、この部分は決して失敗してはなりません。

NDR メッセージの返信アドレスを監視して、電子メールがいつ配信されなかったかが確実にわかったときに何らかのアクションを実行できるようにすることもできます。しかし、ユーザーがまだシステムにログインできない場合、何が起こったのかをユーザーに知らせる良い方法はありません。おそらく、電子メールに関連付けられた値を Cookie に設定し、メールを配信できなかった場合にログイン/登録ページに何かを表示することができます。

Answer 4

私の意見では、再試行せずにユーザーに通知して、電子メールを確認するように依頼する必要があります。

ユーザーが電子メールを確認せずにページを離れた場合、ユーザーはアカウントにアクセスできないため、アカウントをロールバックすることをお勧めします。

タイムアウトのほとんどの場合は、無効な電子メール アカウントが原因で発生します。ユーザーはスパムを避けるために、間違いを犯したか、存在しない電子メール アドレスを指定しました。

可能な限り、ユーザーにメールアドレスを尋ねないでください。プログラミングの第一のルールは次のとおりです。ユーザーに迷惑をかけないでください。