当我为我的 Web 应用程序创建用户时，会使用自动生成的密码向用户发送一封 SMTP 电子邮件（使用 ASP.NET 的 SmtpClient）。但是，有时我注意到它超时并且新用户根本不会收到带有密码的电子邮件。
好的，所以我将显示一条消息，指示邮件未通过但已创建用户。
因此，系统管理员目前有 2 个选项：
如果未发送 smtp，我可以回滚用户创建，但解决此问题的最佳做法是什么？
我在想我应该重试发送电子邮件 3 次，每次超时时间为 5 秒。所以 15 秒是最坏的情况。
这是要走的路吗？
好吧，根据您的平台，如果您可以将邮件交给本地 MTA，它应该处理重试等。您的程序可以将邮件排队并继续前进，而不用担心处理超时和灰名单等。
如果邮件仍然无法发送，您可以随时尝试重新发送（通过密码重置功能）。如果也失败了，很可能是电子邮件地址有误，我建议删除该帐户，导致用户重新注册。
当然，这在某些系统上可能是不可能的，这取决于对未经确认的用户可以做什么——这实际上取决于您允许人们在他们的电子邮件被验证之前做什么。
听起来您的 Web 应用程序正在直接向您用户的邮件服务器发送 SMTP。[您的 Web 应用程序是与用户的 MTA（邮件传输代理）对话的 MUA（邮件用户代理）。] 没有说用户的 MTA 必须可以访问或目前正在工作。您需要运行自己的 MTA，以确保有人提供排队、重试等。
如果你真的想向后弯腰，你可以做你正在做的事情（尽管只有一次尝试），退回到排队消息并继续以较慢的时间表重试至少 24 小时，并将未完成的状态暴露给用户。
可以在RFC1123（Internet 主机要求 - 应用程序和支持）中找到有关您的应用程序应该如何运行的官方答案：
5.3.1.1 发送策略
发件人 SMTP 的一般模型是一个或多个定期尝试传输外发邮件的进程。在典型的系统中，编写消息的程序有一些方法可以请求立即关注新的外发邮件，而不能立即传输的邮件必须排队并由发件人定期重试。邮件队列条目不仅包括邮件本身，还包括信封信息。
发送方必须在一次尝试失败后延迟重试特定目的地。一般来说，重试间隔应该至少30分钟；但是，当发送方 SMTP 可以确定未投递的原因时，更复杂和可变的策略将是有益的。
重试一直持续到消息被传输或发送者放弃；放弃时间一般至少需要4-5天。重试算法的参数必须是可配置的。
恕我直言，您应该通知用户，要求他验证电子邮件，而无需重试。
如果用户没有验证电子邮件并离开页面，您最好回滚帐户，因为用户无论如何都无法访问它。
大多数超时情况是由无效的电子邮件帐户引起的。用户要么犯了错误，要么给了你一个不存在的电子邮件地址，以避免被垃圾邮件。
如果可能的话，不要询问您的用户电子邮件。编程的第一条规则应该是：不要惹恼用户。
如果您使用 ASP.NET 和 System.Net.Mail 类，您可能是通过 Web 服务器计算机上的 IIS 实例发送邮件（我不确定，因为您没有指定）。没有一个好方法可以了解您的邮件传输代理 (IIS SMTP) 发生了什么。它有自己的重试逻辑，默认情况下，可能需要很长时间才能传递消息。
您如何检测到邮件未送达？“超时”从何而来？
您应该有一个处理邮件发送的后台进程。如果成功交付给 MTA，您应该假设一切正常。除非您被列入垃圾邮件黑名单，否则大多数 MTA 会不断重试，直到通过。如果您在使用 MTA 删除消息时确实遇到错误，那么一定要重试，或者找出导致失败的原因并修复错误。老实说，这部分不应该失败。
您可能希望监控 NDR 邮件的返回地址，以便在您确定电子邮件未送达时采取某种措施。但是如果用户还不能登录系统，就没有好办法让他们知道发生了什么。也许您可以设置一个与电子邮件相关联的值的 cookie，如果您无法发送邮件，则在登录/注册页面上放一些东西。