Email RFC 5322是否允许在没有任何实际电子邮件地址的情况下回复邮件头？如果是，它的语义是什么？

将回复标题定义为：

reply-to        =   "Reply-To:" address-list CRLF

其中地址列表定义在。当展开ABNF语法时，我发现地址列表只能由

短语“：”；“

（短语定义在）组成。因此，归根结底，您可以添加一个不包含任何实际电子邮件地址的回复头

RFC声明：

当“回复：”字段存在时，它表示邮件作者建议向其发送回复的地址

即使这只是一个建议，但我可以建议某人回复我的姓名但没有具体说明的地址，这似乎很奇怪

---

我是不是遗漏了什么？我该如何解释这样的结构呢？

您似乎发现了规范中的一个疏忽。很好

如果你阅读了本书的其余部分，你会发现（我的重点）：

当需要治疗几个 邮箱作为单个单元（即，在 （通讯组列表） 可以使用构造。团体 构造允许发送方 指示指定的收件人组。 这是通过提供显示名称来完成的 对于组，后跟冒号， 后跟以逗号分隔的 任意数量的邮箱（包括 零和一），并以 分号因为 邮箱可以为空，请使用 组构造也是一种简单的方法 向收件人传达 消息已发送到一个或多个命名的 收件人的集合，而不是实际的 提供个人邮箱 任何收件人的地址。

这在（例如）To或CC的上下文中是有意义的，但在（例如）From或Reply To的上下文中是没有意义的。通过将“发件人”指定为邮箱列表，他们获得了“发件人”的权限，但他们似乎在回复时弄糟了它

看起来他们应该回复邮箱列表而不是地址列表。可能值得尝试联系IETF工作组以指出错误

[更新]

我已针对该问题提交了RFC 5322的勘误表：

---

让我们看看他们是怎么处理的。

对我来说，将空的

回复

标题视为不应回复邮件的指示似乎是合乎逻辑的。Outlook中有一个功能，可能受到GMail的尊重：-它还用于“NoReplyAll”和“NoReply”选项。我不知道这是某种专有的黑客行为，还是一种将邮件标记为“无回复”的标准化方式（如标题）。勘误表已被拒绝。更新：IETF在2013年3月决定采用另一种方式，即建议制作

from=“from:”（邮箱列表/地址列表）CRLF

。动机：“From:”字段的用例已经演变。有许多自动化系统希望发送电子邮件，但无法处理回复，而没有可用地址的“发件人：”字段将非常有用