Skip to main content

6. Problem Detection and Handling (问题检测与处理)

6.1. Reliable Delivery and Replies by Email (可靠传递和通过电子邮件回复)​

当接收方SMTP接受一封邮件 (通过发送"250 OK"消息响应DATA) 时，它正在接受传递或中继该消息的责任。它必须 (MUST) 认真对待这一责任。它禁止 (MUST NOT) 因琐碎原因丢失消息，例如因为主机后来崩溃或因为可预测的资源短缺。一些不被认为是琐碎的原因在下一小节和第7.8节中讨论。

如果在接受消息后发生传递失败，接收方SMTP必须 (MUST) 制定并邮寄通知消息。此通知必须 (MUST) 使用信封中的空 ("<>") 反向路径发送。此通知的收件人必须 (MUST) 是信封返回路径 (或Return-Path:行) 中的地址。然而，如果此地址为空 ("<>")，接收方SMTP禁止 (MUST NOT) 发送通知。显然，本节中的任何内容都不能或不应该禁止本地决策 (即，作为与接收方SMTP相同的系统环境的一部分) 在需要时在本地记录或以其他方式传输有关空地址事件的信息。如果地址是显式源路由，则必须 (MUST) 将其剥离到其最终跳。

例如，假设必须为到达时带有以下内容的消息发送错误通知:

MAIL FROM:<@a,@b:user@d>

通知消息必须 (MUST) 使用以下内容发送:

RCPT TO:<user@d>

SMTP接受消息后的某些传递失败将是不可避免的。例如，由于"软"域系统错误、因为目标是邮件列表 (参见前面对RCPT的讨论)、或因为服务器充当中继并且无法立即访问传递系统，接收SMTP服务器可能无法验证RCPT命令中的所有传递地址。

为了避免由于超时而接收重复消息，接收方SMTP必须 (MUST) 寻求最小化响应最终<CRLF>.<CRLF>数据结束指示所需的时间。有关此问题的讨论，请参见RFC 1047 [40]。

6.2. Unwanted, Unsolicited, and "Attack" Messages (不需要的、未经请求的和"攻击"消息)​

互联网邮件系统的实用性和可预测性要求能够传递的消息应该被传递，无论与这些消息相关的任何语法或其他故障以及无论其内容如何。如果它们无法传递，并且在SMTP事务期间无法被SMTP服务器拒绝，则应如上所述"反弹" (返回非传递通知消息)。在当今世界，许多SMTP服务器运营商发现不需要的批量电子邮件的数量远远超过所需邮件的数量，并且接受消息可能会通过提供地址验证来触发额外的不需要的流量，这些原则可能不实用。

如下面第7.8节和第7.9节所述，在实践中允许在不通知发送方的情况下丢弃邮件。然而，这是极其危险的，并且违反了长期传统和社区期望，即邮件要么被传递，要么被返回。如果静默消息丢弃被滥用，它很容易破坏对互联网邮件系统可靠性的信心。因此，只有在有很高信心认为消息是严重欺诈性的或以其他方式不适当的情况下，才应考虑静默丢弃消息。

为了尽可能进一步扩展"如果可能则传递"的原则，不传递具有无效返回地址的邮件可能是一项合理的策略，尽管网络的历史表明，用户通常通过传递任何可以传递的消息而得到更好的服务。可靠地确定返回地址无效可能是一个困难且耗时的过程，特别是如果假定的发送系统不可直接访问或不完全且准确地支持VRFY，并且即使采用"丢弃具有无效返回地址的消息"策略，也应该 (SHOULD) 仅在几乎确定返回地址实际上无效时才应用它。

相反，如果消息因发现包含敌对内容而被拒绝 (这是超出本文档中定义的SMTP服务器范围的决定)，则不应该 (SHOULD NOT) 发送拒绝 ("反弹") 消息，除非接收站点确信这些消息将被有用地传递。在这些情况下，当确定传入消息包含敌对内容时，首选项和默认设置是避免发送非传递消息。

6.3. Loop Detection (循环检测)​

简单地计算消息中"Received:"头字段的数量已被证明是检测邮件系统中循环的有效方法，尽管很少是最优的。使用此技术的SMTP服务器应该 (SHOULD) 使用较大的拒绝阈值，通常至少为100个Received条目。无论使用什么机制，服务器必须 (MUST) 包含用于检测和停止简单循环的规定。

6.4. Compensating for Irregularities (补偿不规则性)​

不幸的是，确实会发生互联网邮件协议的变体、创造性解释和彻底违反; 有些人会建议它们经常发生。关于行为良好的SMTP接收方或中继是否应该拒绝格式错误的消息、尝试不加更改地传递它，或尝试修复它以增加成功传递 (或后续回复) 的机会的辩论几乎与结构化网络邮件的黎明一起开始，并且没有停止的迹象。拒绝的倡导者声称尝试修复很少是完全足够的，拒绝错误消息是修复有问题软件的唯一方法。"修复"或"无论如何都传递"的倡导者认为，用户更希望邮件尽可能通过，并且在该方向上存在重大的市场压力。在实践中，这些市场压力对于特定供应商可能比严格符合标准更重要，无论实际开发人员的偏好如何。

分离UA邮件阅读协议 (邮局协议 (POP) 版本2 [15]、邮局协议 (POP) 版本3 [16]、IMAP版本2 [41] 和PCMAIL [42]) 的引入加剧了与格式错误消息相关的问题。这些协议鼓励使用SMTP作为发布 (消息提交) 协议，并使用SMTP服务器作为这些客户端主机 (通常仅间歇性地连接到互联网) 的中继系统。从历史上看，许多这些客户端机器缺少SMTP (实际上是邮件格式协议RFC 822 [28]) 假定的一些机制和信息。有些无法充分跟踪时间; 其他人没有时区概念; 还有一些无法识别自己的名称或地址; 当然，没有一个能够满足RFC 822对经过身份验证的地址的构想所基于的假设。

为了响应这些弱SMTP客户端，许多SMTP系统现在完成以不完整或不正确形式传递给它们的消息。当服务器可以识别或验证客户端，并且它们之间存在事先协议时，此策略通常被认为是适当的。相比之下，对中继或传递SMTP服务器应用的修复充其量存在很大的担忧，该服务器对用户或客户端机器知之甚少或一无所知。通过使用单独的协议 (例如RFC 4409 [18] 中定义的协议) 进行消息提交，而不是为此目的使用发起SMTP服务器，可以解决许多这些问题。

当发起SMTP服务器或用作SMTP目标的初始发布 (消息提交) 协议的服务器必要时，可以 (MAY) 对正在处理的消息应用以下更改:

  • 当没有出现message-id字段时添加它

  • 当没有出现日期、时间或时区时添加它们

  • 将地址更正为正确的FQDN格式

服务器对客户端的信息越少，这些更改正确的可能性就越小，在考虑是否执行修复以及如何执行时应应用的谨慎和保守就越多。这些更改禁止 (MUST NOT) 由提供中间中继功能的SMTP服务器应用。

在所有情况下，提供正确信息的正常运行客户端优于SMTP服务器的更正。在所有情况下，应该 (SHOULD) 在跟踪头字段和/或头字段注释中为服务器执行的操作提供文档。

Last updated on