当我为自己的Web应用程序创建用户时，SMTP电子邮件(使用ASP.NET的SmtpClient)将通过以下方式发送给用户：
自动生成的密码。但是，有时我注意到它超时了，新用户根本不会收到带有密码的电子邮件。

好了，因此我将显示一条消息，指示该邮件没有通过，但是创建了用户。

因此，到目前为止，系统管理员有2个选项：

• 重置用户密码，并希望使用自动生成的密码发送另一封SMTP邮件。
• 删除并重新创建用户。

如果未发送smtp，我可以回滚用户创建，但是解决此问题的最佳实践是什么？

我认为我应该重试发送电子邮件3次，每次超时时间为5秒。因此15秒将是最糟糕的情况。

这是要走的路吗？

解决方案

回答

好吧，取决于平台，如果我们可以将邮件移交给本地MTA，则它应该处理重试等。程序可以将邮件排入队列并继续前进，而不用担心超时和灰名单等问题。

如果仍然无法发送该消息，则可以始终尝试重新发送它(通过密码重置功能)。如果同样失败，则很可能是电子邮件地址有误，我建议删除该帐户，从而导致用户重新注册。

当然，这在某些系统上可能无法实现，这取决于未确认用户的操作，这实际上取决于我们允许人们在验证电子邮件之前执行的操作。

回答

恕我直言，我们应该通知用户，要求他验证电子邮件，而无需重试。

如果用户未验证电子邮件并离开页面，则最好回滚该帐户，因为该用户无论如何都无法访问它。

大多数情况下，超时是由无效的电子邮件帐户引起的。用户可能犯了一个错误，或者给了我们一个不存在的电子邮件地址，以避免被垃圾邮件发送。

如果可能，请不要向用户发送电子邮件。编程的第一法则应该是：不要惹恼用户。

回答

听起来Web应用正在直接将SMTP与用户的邮件服务器对话。
[Web应用是与用户的MTA(邮件传输代理)对话的MUA(邮件用户代理)。]
没什么说用户的MTA必须是可及的或者正在运行。我们需要运行自己的MTA，以便确保有人提供排队，重试等。

如果我们确实想向后弯腰，则可以执行自己的操作(虽然只能尝试一次)，退回到排队消息的状态，并继续以较慢的进度重试至少24小时，然后将未完成的状态暴露给用户。

可以在RFC1123(Internet主机应用程序和支持要求)中找到有关应用程序行为的官方答案：

5.3.1.1 Sending Strategy
  
  The general model of a sender-SMTP is
  one or more processes that
  periodically attempt to transmit
  outgoing mail.  In a typical system,
  the program that composes a message
  has some method for requesting
  immediate attention for a new piece of
  outgoing mail, while mail that cannot
  be transmitted immediately MUST be
  queued and periodically retried by the
  sender.  A mail queue entry will
  include not only the message itself
  but also the envelope information.
  
  The sender MUST delay retrying a
  particular destination after one
  attempt has failed.  In general, the
  retry interval SHOULD be at least 30
  minutes; however, more sophisticated
  and variable strategies will be
  beneficial when the sender-SMTP can
  determine the reason for non-
  delivery.
  
  Retries continue until the message is
  transmitted or the sender gives up;
  the give-up time generally needs to be
  at least 4-5 days.  The parameters to
  the retry algorithm MUST be
  configurable.

回答

如果使用ASP.NET和System.Net.Mail类，则可能是通过Web服务器计算机上的IIS实例发送邮件(我不确定，因为我们未指定)。没有很好的方法来了解邮件传输代理(IIS SMTP)的状况。它具有自己的重试逻辑，默认情况下，传递消息可能需要很长时间。

我们如何检测到邮件未送达？什么是"超时"？

我们应该有一个处理邮件发送的后台进程。如果成功传送到MTA，则应该假设一切都很好。除非我们被列入垃圾邮件黑名单，否则大多数MTA都会一直重试，直到获得通过为止。如果我们在使用MTA传递消息时确实遇到错误，则可以肯定地重试它，或者找出导致故障的原因并修复错误。老实说，这部分应该永远不会失败。

我们可能希望监视NDR邮件的回信地址，以便在确定何时未发送电子邮件时可以采取某种措施。但是，如果用户仍无法登录系统，则没有很好的方法让他们知道发生了什么。也许我们可以使用与电子邮件相关联的值来设置Cookie，如果无法传递邮件，则可以在登录/注册页面上添加一些内容。