SMTP错误代码合规性

时间:2009-10-04 08:50:01

标签: smtp

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

无论如何,我遇到目标SMTP服务器返回错误代码的问题,该错误代码与错误消息不符。因此,我无法将交货标记为硬或软弹跳。例如。回复错误代码为450(表示邮箱不可用),但回复邮件与超时有关。当我再次发送相同的消息时,它就通过了。显然是上一次发送的超时问题。

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

是否有人遇到类似的问题,你如何处理它。

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

1 个答案:

答案 0 :(得分:3)

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

灰名单是一种反垃圾邮件方法,其工作方式是软件失败,因为合法的MTA会在一段时间后尝试重新提交邮件。不幸的是,有两件事对你有利:

  • 灰名单时段可以随机选择。这意味着有时在接受邮件传递之前需要多次重试。
  • 虽然4xx代码应始终被视为软故障并用于此目的,但服务器无需告知您它是由灰名单引起的。有些人会很善良,有些则不会。

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