Email 如何准确解析smtp邮件状态代码（DSN）？

RFC1893声称状态代码将采用以下格式，您可以阅读更多

但是我们的反弹管理系统很难解析反弹消息中的错误状态代码。我们能够获得原始消息，但根据电子邮件服务器的不同，代码将出现在不同的位置。关于如何解析此类消息以获得更好的结果，是否有任何规则。我们不是在寻找100%的解决方案，而是至少80%

本文档定义了一组新的状态代码，用于报告邮件系统 条件这些状态代码用于介质和设备 独立于语言的状态报告。它们不适用于 系统特定诊断

新状态代码的语法 定义如下：

      status-code = class "." subject "." detail
      class = "2"/"4"/"5"
      subject = 1*3digit
      detail = 1*3digit

空白字符和注释 不允许出现在状态中-
代码。内的每个数字子代码 必须表示状态代码
没有前导零位

上面来自RFC的引用说明了一件事，但下面来自bounce management的主要工具的文本说明了一些不同的内容，我可以从中获得标准状态代码的良好来源：

返回代码说明
0未确定-（即收件人回复）
10硬反弹-（即用户未知）
20软弹跳-概述
21软弹跳-Dns故障
22软弹跳-邮箱已满
23软弹跳-消息太大
30弹跳-没有电子邮件地址。非常罕见
40一般反弹
50个邮件组-常规
51邮箱-已知垃圾邮件发送者
52邮件阻止-检测到垃圾邮件
53邮件阻止-检测到附件
54邮件阻止-中继被拒绝
60自动回复（即不在办公室）
70瞬时反弹
80订阅请求
90取消订阅/删除请求
100挑战-反应

---

我不确定这是否是一个完整的答案，但可能有用。

这非常有帮助。你有没有在你的开发项目中使用过这个项目？不能说我用过，但它看起来确实解决了你正在处理的同一个问题。我不知道您的开发环境，所以我也不能说您是否应该考虑使用该项目，或者将ReGEXP算法适应您的需要。但是任何有效的例子都必须比dry RFC好。你的链接已经失效。来自“领先工具”的状态代码是他们自己的“时事通讯”管理系统的专有代码。DSN没有提到订阅或垃圾邮件。看看