SMTP 错误代码合规性

Question

我不太确定这是否是提出这个问题的最佳地点(或在 serverfault 处)。我正在使用第 3 方 .NET SMTP 组件将电子邮件直接发送到收件人的邮件服务器。我需要这样做才能获得交付的实时结果。通过另一个 SMTP 服务器发送需要我通过 DSN 报告异步获取结果，这对于我的应用程序的性质来说太麻烦了。

无论如何，我遇到了目标 SMTP 服务器返回与错误消息不符的错误代码的问题。因此，我无法将交付标记为硬退回或软退回。例如。回复错误码是 450(意思是邮箱不可用)，但是回复消息跟超时有关。当我再次发送相同的消息时，它通过了。显然是前一次发送的超时问题。

我也意识到，问题可能不是接收 SMTP 服务器，而是防火墙/代理(无论你怎么称呼它)，它正在保护服务器。

有没有人遇到过类似的问题，你是如何处理的。

PS:当我回到办公室时，我会尝试从我的日志中提供更多详细信息。

Answer 1

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

灰名单是一种反垃圾邮件方法，它的工作原理是基于合法 MTA 将在一段时间后尝试重新提交邮件的基础上使传递软失败。不幸的是，有两件事对您不利:

灰名单周期可以随机选择。这意味着有时需要多次重试才能接受消息进行传递。

尽管 4xx 代码应始终被视为软故障并用于此目的，但没有任何要求服务器告诉您这是由于灰名单造成的。有些人会很友善，有些人则不会。

您如何处理将取决于软故障是否被视为您的应用程序正在执行的目的的最终故障。如果不是，那么您将不得不设计一些可靠的排队和重试。我对您的诚实建议是，实现可靠的 DSN 或日志检查可能比发明您自己的符合 RFC(和 quirk)的 MTA 更容易。