SMTP错误代码合规

Question

我不太确定这是否构成此问题的最佳位置（或在服务器默认情况下）。我正在使用第三方.NET SMTP组件直接向收件人的邮件服务器发送电子邮件。我需要这样做才能获得实时的交付结果。通过另一个SMTP服务器发送需要我通过DSN报告异步获取结果，这对我的应用程序的性质来说太麻烦了。

无论如何，我遇到了与目标SMTP服务器返回的错误代码不符合错误消息的问题。因此，我不能将交付标记为硬性或软性反弹。例如。回复错误代码是450（表示邮箱不可用），但是回复邮件与超时有关。当我再次发送相同的消息时，它已经过了。很明显，以前的发送超时问题。

我意识到，问题可能不是接收SMTP服务器，而是防火墙/代理（无论您称之为什么），即保护服务器。

有没有人遇到类似的问题，你如何处理它。 PS：当我回到我的办公室时，我会尽量从我的日志中提供更多详细信息。

Answer 1

听起来像灰名单。这很有趣，因为当我开始阅读你的问题时，那是我可以预见的第一个障碍之一。

Greylisting是一种反垃圾邮件方法，其工作原理是在合法MTA尝试在一段时间后重新提交邮件的基础上软交付失败。不幸的是，有两件事情对您不利：

• 灰名单可以随机选择。这意味着有时在接收邮件接收邮件前需要多次重试。
• 尽管4xx代码应该总是被视为软故障并用于此目的，但服务器没有任何要求告诉您这是归因于灰名单。有些会如此善良，有些则不会。

您如何处理这将取决于软故障是否被认为是您的应用程序正在执行的最终失败。如果他们不是，那么你将不得不设计一些可靠的排队和重试。我诚挚的建议是，实现可靠的DSN或日志检查可能比创建自己的符合RFC（和quirk）的MTA更容易。