error-handling - 如何处理 SMTP 超时

Question

我正在使用用 C# 编写的客户端应用程序向公司交换服务器发送批量电子邮件。

客户端应用程序超时(而不是服务器)可能会发生，并且确实发生了。
由于无法知道服务器是否完成了请求，这种情况下如何处理重试？

没有涉及可用于避免重复的 ID。
设置长超时甚至无限超时都不是一个好策略。

我正在使用指数退避算法进行重试。在这种情况下，它应该只发送一个副本，因为下次它会等待更长的时间。

我认为没有子弹教授解决方案。无论如何，由于它是第一个此类项目，我需要检查是否有人有我想念的解决方案。

更新 :
交易所正在做中继。我正在使用 SmtpClient 发送电子邮件。
问题是服务器可以发送 250 Ok 消息，但接收方始终没有收到，然后重试。这是我在这篇文章中试图解决的唯一问题。

在 Rest 服务中，推荐的方法是使用并发错误。如果客户端发布某些内容并获得“409 - 冲突”状态，则表示该消息已存储在服务器上。但是为了让这种情况发生在那里，它是由客户端创建的消息的 key ，并且是消息的一部分。
SMTP 似乎没有可以防止这种情况的机制。

Answer 1

通常，在使用标准 SMTP 时，如果他接受电子邮件，SMTP 服务器会给您一个信息。下面是一个通过 telnet 的例子:


因此，您的应用程序只需要在此处跟踪响应，如果发生超时，您不需要继续处理所有电子邮件，而需要在它停止的地方继续。顺便说一句，您的应用程序应该在每次响应时检查，因为它可能是发送者或接收者不被接受......
这在 RFC 5321 中有所提及(您可以在该文档中滚动):

When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage. [...] When the end of text is successfully received and stored, the SMTP-receiver sends a "250 OK" reply.

当您发送电子邮件时，我认为第 4.5.4.1 节。如果您不使用某种框架来处理符合 RFC 的外发电子邮件，这可能很重要。
示例:您的客户正在生成一封电子邮件，但在从正文提交期间(电子邮件传输的最后一部分)连接断开。然后不允许服务器继续发送电子邮件。从技术上讲，他可能会获得所有信息，但 RFC 不允许他将其发送出去，因为客户端超时并且没有完成整个过程。
更新:
最好的方法是使用 C# SmtpClient method然后检查 smtpStatusCode确定(=“电子邮件已成功发送到 SMTP 服务。”)您也可以在 telnet 示例中看到。该方法在这里(技术上)没有做任何其他事情。该方法也符合 RFC 5321，因此您无需重新发明 smtp 发送轮。如果您在此期间没有得到 OK，则可能发生了某些事情，您需要检查结果然后重新发送(或者如果错误消息表明电子邮件地址无效或需要放弃，或者类似的东西以避免无限循环)。