是否允许根据链中的 IP 地址拒绝电子邮件?

是否允许根据链中的 IP 地址拒绝电子邮件?

一家大型 ISP 拒绝电子邮件(退回并显示错误 550),理由是传输链中的 IP 地址在其“阻止列表”中。他们是否可以这样做并且仍然符合 IETF 要求?

我能找到的只有 RFC 2821:

SMTP 服务器可以验证 EHLO 命令中的域名参数是否
确实与客户端的 IP 地址相对应。但是, 如果验证失败,
服务器不得因此而拒绝接受邮件:有关验证 失败的信息仅用于记录和跟踪

这表明系统不能拒绝电子邮件,尽管场景不同。

有人可以启发我们吗?

答案1

可以说RFC 的是为了保持互联网的正常运转和互联互通,而垃圾邮件则是一种滥用。

这意味着也没有 RFC 或其他标准来定义“这是垃圾邮件” ;创建这样的标准意味着所有不符合“标准垃圾邮件”的东西都不应被阻止,而必须投递……

因此垃圾邮件和非垃圾邮件的分类是任意的并完全取决于接收者(所使用的系统)。

一旦电子邮件被识别为垃圾邮件,收件人大致有三种选择:

  • 接受垃圾邮件- 但不要将邮件直接发送到收件人的收件箱,隔离邮件,标记邮件和/或将其发送到垃圾邮件文件夹。
  • 接受垃圾邮件并默默丢弃- 可以说,这违反了历史上的 SMTP 概念和标准,发件人不会收到其邮件未送达的通知,而预期的接收者仍然不知道有人试图联系他们。参见RFC 5321 - §6.2何时才可以允许这样做。
  • 拒绝垃圾邮件- 尽管你想避免背向散射正确拒绝该消息将导致向发件人发送未送达错误消息(在出现误报的情况下很重要)

拒绝垃圾邮件的正确且符合标准的方法是,当发送邮件服务器仍处于连接状态且在 SMTP 事务期间时,以 SMTP 错误进行响应。例如,这可能是 400 范围内的错误,也可能是 500 范围内的错误:

5yz   Permanent Negative Completion reply
  The command was not accepted and the requested action did not
  occur.  The SMTP client is discouraged from repeating the exact
  request (in the same sequence).  Even some "permanent" error
  conditions can be corrected, so the human user may want to direct
  the SMTP client to reinitiate the command sequence by direct
  action at some point in the future (e.g., after the spelling has
  been changed, or the user has altered the account status).

RFC 2821——§4.2.3

  550 Requested action not taken: mailbox unavailable
     (e.g., mailbox not found, no access, or command rejected
     for policy reasons)

发送邮件服务器仍然可以清楚地向真正的发件人报告问题,而不会导致反向散射。

相关内容