SMTP 错误代码合规性

Question

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

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

我也意识到，问题可能不是接收 SMTP 服务器，而是保护服务器的防火墙/代理（不管你怎么称呼它）。

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

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

Answer 1

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

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

• 灰名单周期可以随机选择。这意味着有时需要多次重试才能接受消息传递。
• 虽然 4xx 代码应始终被视为软故障并用于此目的，但服务器没有任何要求告诉您这是由于灰名单。有些人会很友善，有些人不会。

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