有一个“无回复”电子邮件标题吗？

Question

我经常看到自动化的电子邮件后面附有类似以下信息的消息：

亚马逊：

*请注意：此电子邮件是由无法接收传入电子邮件的地址发送的。 如果您需要再次联系我们解决同样的问题，请使用上面提供的链接。

推特：

请勿回复此消息； 它是从未被监控的电子邮件地址发送的。此消息是与您使用Twitter相关的服务电子邮件。

Google Checkout：

需要帮助？访问Google Checkout帮助中心。 请勿回复此消息。

就在这个警告下面，Gmail向我显示了一个回复输入框。 我认为应该有某种头文件可以附加到这样的自动化电子邮件上，以告诉收件人的电子邮件客户端不允许回复。

是否有这样的标题？ 如果没有，控制电子邮件格式的组曾经讨论过吗？

- Evan Krall

---

此链接是关于转发的，但也有一个选项可以禁用回复或回复所有收件人：https://www.makeuseof.com/tag/prevent-emails-forwarded-outlook-gmail/ - 有人知道它是如何在底层运作的（电子邮件头部）吗？ - Tomasz Gandor

@TomaszGandor 他们两个都不使用标题。Gmail的那个从不通过电子邮件发送您的内容，只会发送一个即将过期的访问代码，以加载您实际上并未发送的内容。Outlook的那个会使用收件人的公钥对内容进行加密。“转发”邮件可能不会使用新收件人的密钥重新加密。总的来说，信息总是可以复制的。如果有人能够接收内容并（如果相关）解密它，他们就可以记录下来并发送给任何愿意听的人。 - undefined

Answer 1

这样的标题存在吗？ 没有。我非常确定没有这样的东西，即使有，它也是非标准的且不被广泛支持，因此目前基本上没有用处。即使它成为标准，任何这样的标题都只能是信息性的；并且为了向后兼容性，对于电子邮件客户端而言支持必须是完全可选的。客户端将会很慢地实现它，许多用户仍将使用旧版本的邮件客户端。

如果不存在，那么控制电子邮件格式的组是否曾经讨论过它？ 可能。人们已经有很长时间提出各种各样的电子邮件想法，但我的直觉是这永远不会被实现；嗯……除非关于电子邮件所设计的基本思想发生根本性转变。 我确信谷歌会更高兴，如果他们给你发送电子邮件时，你甚至没有一个“回复”按钮，所以如果有人正在推动这个功能，那么就是那些已经从 donotreply@...发送邮件的人。

电子邮件的设计是用于发送真实邮箱的。RFC 2822和RFC 5322说：

在所有情况下，“From:”字段都不应包含任何不属于消息作者的邮箱。

对我来说，这是一个清楚的指示，电子邮件被设计为一种对话方式，而不是广播。

任何改变的最大障碍可能是该行上方的那个小部分，它需要被完全重新定义；这将引起比解决更多问题：

原始字段也提供了回复消息所需的信息。当存在“回复”字段时，它指示应将答复发送到哪个地址。如果缺少“回复”字段，则默认情况下应将答复发送到“From:”字段中指定的邮箱，除非撰写答复的人另有说明。

- SimonMayer

---

我强烈反对你的解释，认为邮箱应该属于消息的作者。无回复电子邮件属于作者，并且不期望有任何交流... - AlxVallejo

Answer 2

RFC 6854 更新了RFC 5322，允许在From字段中也使用组结构（以及其他内容）。一个组可以为空，这可能是您看到的唯一使用组语法的方式： undisclosed-recipients:;。

RFC 的第1节明确列出了“no-reply”作为允许在From字段中使用组结构的动机之一：

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

它提供了以下示例：From: Automated System:;

然而，在同一节的结尾处，RFC还说：

目前不推荐在这些领域中普遍使用组语法。

在第3节中，RFC澄清了From字段中的组语法仅供有限使用。

我个人认为，除非我们确信所有相关客户端以其他方式显示起始域（从Return-Path或新标题重构），否则不应使用此方法。否则，这将使所有关于域验证（SPF、DKIM和DMARC）的努力都无用武之地。引入一个导致客户端简单隐藏回复按钮的附加标头字段似乎对我来说是更好的方法。

RFC在第5节中就此方面发表评论：

有些协议试图通过将“From:”地址与特定验证域匹配来验证发件人地址的有效性（对于其中一个协议，请参见作者域签名实践（ADSP）文档[RFC5617]）。这种协议不适用于缺少“From:”字段中实际电子邮件地址（无论是真实还是伪造）的消息。本地策略将决定如何处理此类消息，因此，发件人需要意识到在“From:”中使用组可能会对消息的可交付性产生负面影响。

多么错失的机会啊...

- Kaspar Etter

Answer 3

似乎Thunderbird会显示内置警告消息，如果“From”地址的形式为“[e-mail]”。 （我注意到的这条消息也有“To”与“[e-mail]”，并且我的电子邮件地址仅在“Cc”字段中。我没有测试这是否重要。）

据我所知，表单“[e-mail]”尚未在任何RFC中定义。

更新：看起来这种行为已经在此错误中实现：https://bugzilla.mozilla.org/show_bug.cgi?id=1342809和实际实现是一个正则表达式。

/^(.*[._-])?(do[._-]?not|no)[._-]?reply([._-].*)?@/

如果匹配成功，将显示确认提示：

不支持回复

回复地址（{$email}）似乎不是一个被监控的地址。发送到此地址的消息可能不会被任何人阅读。

[仍要回复] [取消]

对我来说，这似乎很合理，其他供应商可能也会同意。请注意，这会导致在允许回复之前显示以下警告：

[e-mail]
[e-mail]
[e-mail]
[e-mail]

很遗憾，它不匹配

[e-mail]

所以你必须使用类似于的东西

[e-mail]

如果您想在标签部分编码额外信息。

更新：请注意，这些内容都没有在任何与电子邮件相关的RFC中指定，因此这是关于实际操作而不是理论方面的问题。

- Mikko Rantalainen

---

在标签部分 - 请注意，这 不 是一项标准功能，并且您不能依赖它通常有效。这是由 一些 邮件服务器采用的行为。但是，除非您了解特定服务器的配置，否则假设 [e-mail] 和 [e-mail] 将最终进入同一个邮箱是错误的。并且对于任何类型的特殊用途自动回复器进行测试，使用 + 表单可能很容易不起作用。此外，我不喜欢将信息编码在那里; 考虑消息 ID（个人）和/或列表 ID（类别）。 - Chris Morgan

@ChrisMorgan 您说得完全正确，根据RFC规范，系统应该按照您所描述的方式工作。整个本地部分（包括“+”）都应该对发送者不透明。然而，在实践中，如果用户尝试回复，您不能期望除了“Reply-To”头中的信息之外的任何其他信息都会反映回来，因此为了对不正确的回复做出改进，所有数据必须编码在地址中。并且，由于某些Windows软件中甚至“Reply-To”头也存在问题，您应该尝试将整个内容放在“From”头中。这是实际可行的方法。 - Mikko Rantalainen

Message-ID将出现在回复的In-Reply-To和References中。除此之外，你很可能在整个过程中使用了错误的工具。（还有主题行，应该根据需要进行分类。） - Chris Morgan

不幸的是，并非所有邮件代理都正确填写“In-Reply-To”和“References”头。而且你说得对，我讨论的情况是一个特殊情况，即（1）尝试发送无回复电子邮件和（2）在某人仍然回复该电子邮件的情况下具有后备处理。对于（2），我假设邮件代理只做最少的工作，也就是将原始“From”地址镜像到回复的“To”字段中。 - Mikko Rantalainen

你能否确定任何未设置这两个标头的邮件代理？（我没有进行详细调查，但我所知道的所有代理都设置了。） - Chris Morgan

我不知道当前是否有任何邮件代理程序无法做到这一点，但我记得在2005年至2010年期间曾经与多个代理实现进行过斗争，并且我完全预计某些供应商仍在使用错误的实现。由于SMTP默认仍使用7位传输编码，因此我认为客户端中仍在运行许多旧设备。 - Mikko Rantalainen