SMTP 邮件超时问题

好吧，根据您的平台，如果您可以将邮件移交给本地 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，其中包含与电子邮件关联的值，如果您无法投递邮件，请在登录/注册页面上放置一些东西。