當我爲我的Web應用程序創建用戶時，使用 自動生成的密碼將SMTP電子郵件（使用ASP.NET的SmtpClient）發送給用戶。但是，有時我注意到它超時，新用戶根本不會收到帶有密碼的電子郵件。SMTP郵件超時問題
好的，所以我會顯示一條消息，指出郵件沒有通過但創建了用戶。
因此，系統管理員有2個選項至今：
一）重置用戶密碼，並希望其他SMTP郵件與自動生成的密碼發送。 b）刪除並重新創建用戶。
如果未發送smtp，我可以回滾用戶創建，但解決此問題的最佳做法是什麼？
我在想，我應該重試發送電子郵件3次，每次超時時間爲5秒。所以15秒將是最糟糕的情況。
這是要走的路嗎？
那麼，根據你的平臺，如果你只是把你的郵件交給本地MTA，它應該處理重試等。您的程序只需排隊郵件並繼續前進，而不用擔心處理超時和重排列表等問題。
如果郵件仍然無法發送，您可以嘗試重新發送郵件（通過密碼重置功能）。如果這也失敗了，很可能是電子郵件地址中有錯誤，我建議刪除該帳戶，導致用戶重新註冊。
當然，這在某些系統上可能無法實現，具體取決於未經確認的用戶可以做什麼 - 這取決於您允許用戶在驗證電子郵件之前執行的操作。
恕我直言，你應該通知用戶，要求他驗證電子郵件，而不重試。
如果用戶未驗證電子郵件並離開頁面，則最好回滾該帳戶，因爲無論如何用戶無法訪問該帳戶。
大多數超時情況將由無效的電子郵件帳戶引起。用戶要麼犯了一個錯誤，要麼給你一個不存在的電子郵件地址，以避免被垃圾郵件。
如果可能，請勿要求您的用戶發送電子郵件。 Yhe編程的第一條規則應該是：不要惹惱用戶。
這聽起來像你的網絡應用程序直接向用戶的郵件服務器發送SMTP。 [您的網絡應用程序是與用戶的MTA（郵件傳輸代理）交談的MUA（郵件用戶代理）。] 沒有說用戶的MTA此刻必須可到達或正在工作。你需要運行你自己的MTA，以確保有人提供排隊，重試等。
如果你真的想向後彎，你可以做你正在做的事（儘管只有一個嘗試），回退到排隊消息並繼續以較慢的時間表重試至少24小時，並將該未完成狀態暴露給用戶。
在您的應用程序應該是怎樣表現的官方答案可以在RFC1123 (Requirements for Internet Hosts - Application and Support)發現：
5.3.1.1發送策略
寄件人SMTP的一般模式是 一個或多個進程即 定期嘗試傳送 傳出郵件。在典型的系統中， 對構成消息 程序有用於請求 爲一條新的 傳出郵件立即注意一些方法，而不能 立即發送郵件必須是 排隊並通過 發件人定期重試。郵件隊列條目 不僅包括郵件本身 還包括信封信息。
在一次 嘗試失敗後，發送方必須延遲重試 特定目的地。一般而言， 重試間隔應該至少爲30分鐘 分鐘;然而，更復雜的 和可變策略將是 有益的時候，發件人SMTP可以 確定非 交付的原因。
重試繼續，直到消息被傳送或發送者放棄了 ; 放棄時間一般至少需要4-5天 。重試算法的參數必須爲 可配置。
如果您使用的是ASP.NET和System.Net.Mail類，則可能是通過Web服務器上的IIS實例發送郵件（我不確定，因爲您沒有指定） 。知道郵件傳輸代理（IIS SMTP）發生了什麼並不是一個好方法。它有自己的重試邏輯，並且默認情況下，消息傳遞可能需要很長時間。
您如何檢測郵件未送達？什麼是「超時」來自？
你應該有一個處理郵件發送的後臺進程。如果交付給MTA成功，你應該假設一切都很好。除非你被列入垃圾郵件黑名單，否則大多數MTA都會繼續重試直到他們通過。如果您實際發生的錯誤將您的MTA信息刪除，那麼一定要重試它，或者找出導致失敗的原因並修復錯誤。老實說，這部分應該永遠不會失敗。
您可能希望監控NDR郵件的返回地址，以便您在確定電子郵件未送達時能夠採取某種行動。但是如果用戶無法登錄到系統，那麼沒有辦法讓他們知道發生了什麼。也許你可以用一個與電子郵件關聯的值設置一個cookie，如果你無法發送郵件，可以在登錄頁面註冊一些東西。