13

我经常看到自动电子邮件后缀有这样的消息

亚马逊：

*请注意：这封电子邮件是从一个不能接受来电的地址发出的。如果您需要再次就同一问题与我们联系，请使用上面的链接。

推特：

请不要回复这个信息; 它是从一个不受监控的电子邮件地址发送的。此消息是与您使用 Twitter 相关的服务电子邮件。

谷歌结帐：

需要帮忙？访问 Google Checkout 帮助中心。请不要回复这个信息。

在此警告的正下方，Gmail 向我显示了一个回复输入字段。在我看来，应该有某种标题可以附加到这样的自动电子邮件中，告诉收件人的电子邮件客户端不允许回复。

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

4

3 回答 3

10

有这样的标题吗？

不，我很确定没有这样的事情；即使有，它也是非标准的，也没有得到广泛的支持，所以目前它几乎没用。即使它成为标准，任何这样的标题也可能只是信息性的；为了向后兼容，电子邮件客户端的支持必须完全是可选的。客户端实现它的速度会很慢，而且许多用户仍然使用旧版本的邮件客户端。

如果没有，控制电子邮件格式的小组是否曾讨论过它？

大概。人们已经有很长一段时间通过电子邮件提出各种建议，但我的直觉是它永远不会被实施。好吧...除非电子邮件的设计目的发生根本性转变，否则不会。我敢肯定，如果你在给你发邮件时甚至没有“回复”按钮，谷歌会更开心，所以如果有人在推动它，那将是那些已经发送邮件的人 donotreply@...

电子邮件旨在从真实邮箱发送。RFC 2822 和 RFC 5322 说：

在所有情况下，“发件人：”字段不应包含任何不属于邮件作者的邮箱。

对我来说，这清楚地表明电子邮件被设计为一种对话方式，而不是广播方式。

可能任何变化的最大杀手将是那条线之上的一点点，这需要完全重新定义；这将导致比解决的问题更多的问题：

发起人字段还提供回复消息时所需的信息。当“Reply-To：”字段出现时，它指示消息作者建议将回复发送到的地址。在没有“Reply-To:”字段的情况下，除非撰写回复的人另有说明，否则回复应该默认发送到“From:”字段中指定的邮箱。

于 2012-03-06T22:48:26.813 回答
3

不，没有no-reply标题。

但是，您可以添加一个空reply-to标题：

reply-to: <>

根据RFC 5322, Section 3.6.2有效。不幸的是，RFC 从未真正指定空reply-to字段的含义。我认为大多数电子邮件客户只是忽略它。

于 2014-08-15T18:33:12.033 回答
3

RFC 6854更新了RFC 5322以允许在该From领域中使用组构造（除其他外）。组可以为空，这可能是您见过使用组语法的唯一方式：undisclosed-recipients:;.

RFC 的第 1 节明确列出了允许在该From字段中进行组构造的动机中的“不回复”：

“发件人：”字段的用例已经发展。有许多自动化系统的实例希望发送电子邮件但无法处理回复，并且没有可用地址的“发件人：”字段对于该目的非常有用。

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

但是，在同一部分的末尾，RFC 还说：

本文档目前建议不要在这些字段中普遍使用组语法

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

就我个人而言，我认为不应该使用这种方法——除非我们确定所有相关的客户端都以其他方式显示原始域（从Return-Path或新的标头重建）。否则，这会破坏域身份验证（SPF、DKIM 和 DMARC）的所有努力。引入一个额外的标题字段使客户简单地隐藏回复按钮似乎对我来说是更好的方法。

RFC 在第 5 节中对此方面的评论：

一些协议尝试通过将“发件人：”地址与特定的已验证域匹配来验证始发者地址（对于这样的协议，请参阅作者域签名实践 (ADSP) 文档 [RFC5617]）。此类协议不适用于在“发件人：”字段中缺少实际电子邮件地址（无论是真实的还是虚假的）的邮件。本地策略将决定如何处理此类邮件，因此发件人需要注意，在“发件人：”中使用组可能会对邮件的可传递性产生不利影响。

多么失败的机会……</p>

于 2020-09-01T14:28:23.733 回答