0

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

では、メールは通らなかったがユーザーは作成されたというメッセージを表示します。

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

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

SMTP が送信されない場合、ユーザーの作成をロールバックできますが、この問題に取り組むためのベスト プラクティスは何ですか?

メールの送信を 5 秒間隔で 3 回再試行する必要があると考えています。したがって、15 秒は最悪のシナリオです。

これは行く方法ですか？

4

4 に答える 4

1

プラットフォームにもよりますが、ローカルの MTA にメールを渡すことができれば、再試行などを処理する必要があります。あなたのプログラムは、タイムアウトやグレーリストなどの処理について心配することなく、メールをキューに入れて先に進むことができます.

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

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

于 2008-09-11T18:56:16.477 に答える
1

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

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

アプリの動作に関する公式の回答は、RFC1123 (Requirements for Internet Hosts - Application and Support) にあります。

5.3.1.1 送信戦略

送信側 SMTP の一般的なモデルは、発信メールの送信を定期的に試行する 1 つまたは複数のプロセスです。典型的なシステムでは、メッセージを作成するプログラムには、送信メールの新しい部分に対する即時の注意を要求するための何らかの方法がありますが、送信者はすぐに送信できないメールをキューに入れ、定期的に再試行する必要があります。メール キュー エントリには、メッセージ自体だけでなく、エンベロープ情報も含まれます。

送信者は、1 回の試行が失敗した後、特定の宛先への再試行を遅らせる必要があります。一般に、再試行間隔は 30 分以上にする必要があります。しかしながら、送付者-SMTPが不達の理由を決定できるとき、より洗練されて可変的な戦略は有益でしょう。

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

于 2008-09-11T19:06:52.333 に答える
0

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

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

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

可能な限り、ユーザーのメールアドレスを尋ねないでください。プログラミングの第 1 のルールは次のとおりです。ユーザーを困らせないこと。

于 2008-09-11T18:56:39.270 に答える
0

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

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

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

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

于 2008-09-11T19:24:33.337 に答える