Question

我经常看到自动电子邮件后缀为

之类的消息

亚马逊：

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

Twitter的：

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

Google Checkout：

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

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

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

Answer 1

有这样的标题吗？

没有。我很确定没有那样的东西;即使有，它也是非标准的，没有得到广泛支持，所以目前它几乎没用。即使它成为标准，任何这样的标题可能只是信息性的;对于向后兼容性，对于电子邮件客户端，支持必须完全是可选的。客户端实施起来会很慢，许多用户仍然会使用旧版本的邮件客户端。

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

可能。人们花了很长时间用电子邮件来表达各种各样的事情，但我的直觉是它永远不会实现;好吧......除非电子邮件的设计理念发生根本转变。如果你在给他们发电子邮件时甚至没有“回复”按钮，我肯定谷歌会更高兴，所以如果有人推动它，那么那些已经从donotreply@...发送的人就是

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

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

对我而言，这清楚地表明电子邮件被设计为对话而非广播的方法。

任何改变的最大杀手可能是略高于该线，这需要完全重新定义;这将导致比解决更多的问题：

发起人字段还提供所需的信息回复邮件。当存在“Reply-To：”字段时，它表示消息作者建议的地址回复被发送。如果没有“回复：”字段，默认情况下应该回复应该发送到。中指定的邮箱 “来自：”字段除非组成人员另有说明回复。

Answer 2

不，没有no-reply标题。

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

reply-to: <>

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

Answer 3

RFC 6854更新RFC 5322，以允许在From字段中使用组构造（以及其他功能）。群组可以为空，这可能是您曾经看到过使用群组语法的唯一方法：undisclosed-recipients:;。

RFC的

Section 1在允许From字段中进行组构造的动机中明确列出了“不答复”：

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

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

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

此文档建议此时不要在这些字段中普遍使用组语法

在section 3中，RFC澄清了From字段中的组语法仅适用于Limited Use。

就我个人而言，我认为不应使用此方法-除非我们确定所有相关客户端都以其他某种方式（从Return-Path或新的标头重构）显示原始域。否则，这将挫败所有针对域认证（SPF，DKIM和DMARC）的努力。对我来说，引入一个额外的标题字段使客户仅隐藏回复按钮似乎是更好的方法。

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

某些协议尝试通过将“发件人：”地址与特定的经过验证的域进行匹配来验证始发者地址（有关一种这样的协议，请参见作者域签名实践（ADSP）文档[RFC5617]）。此类协议不适用于在“发件人：”字段中缺少实际电子邮件地址（真实或伪造）的邮件。本地政策将决定如何处理此类消息，因此，发件人需要意识到，在“发件人：”中使用组可能会对消息的可传递性产生不利影响。

多么失败的机会……

是否有“无回复”电子邮件标题？

亚马逊：

Twitter的：

Google Checkout：

3 个答案: