Eva*_*all 11 email rfc822 rfc2822 rfc5322
我经常看到自动电子邮件后缀有一条消息
*请注意:此电子邮件是从无法接收传入电子邮件的地址发送的.如果您需要再次就此问题与我们联系,请使用上面的链接.
请不要回复这个信息; 它是从一个不受监控的电子邮件地址发送的.此消息是与您使用Twitter相关的服务电子邮件.
需要帮忙？访问Google Checkout帮助中心.请不要回复这个信息.
直接在此警告下方,Gmail会向我显示回复输入字段.在我看来,应该有一些标题可以附加到这样的自动电子邮件,告诉收件人的电子邮件客户端不允许回复.
有这样的标题吗？如果没有,控制电子邮件格式的团体是否曾经讨论过它？
Sim*_*yer 10
有这样的标题吗？
不,我很确定没有那样的东西; 即使有,它也是非标准的,没有得到广泛支持,所以目前它几乎没用.即使它成为标准,任何这样的标题可能只是信息性的; 对于向后兼容性,对于电子邮件客户端,支持必须完全是可选的.客户端实施起来会很慢,许多用户仍然会使用旧版本的邮件客户端.
如果没有,控制电子邮件格式的团体是否曾经讨论过它？
大概.人们花了很长时间用电子邮件来表达各种各样的事情,但我的直觉是它永远不会实现; 好吧......除非电子邮件的设计理念发生根本转变.如果你在给他们发电子邮件时甚至没有"回复"按钮,我肯定Google会更高兴,所以如果有人推动它,那么那些已经发送过来的人就是 donotreply@...
电子邮件旨在从真实邮箱发送.RFC 2822和RFC 5322说:
在所有情况下,"发件人:"字段不应包含任何不属于邮件作者的邮箱.
对我而言,这清楚地表明电子邮件被设计为对话而非广播的方法.
可能是任何变化的最大杀手可能是略高于该线,这需要完全重新定义; 这将导致比解决更多的问题:
发起者字段还提供回复消息时所需的信息.当存在"Reply-To:"字段时,它指示消息的作者建议发送回复的地址.如果没有"回复:"字段,默认情况下应该回复应该发送到"发件人:"字段中指定的邮箱,除非组成回复的人员另有说明.
RFC 6854更新了RFC 5322，以允许组构造也可以在From现场使用（除其他外）。组可以为空，这可能是您见过使用组语法的唯一方式：undisclosed-recipients:;。
RFC第 1 节明确列出了允许在该领域构建小组的动机之一：“不回复” From：
\n\n“发件人：”字段的用例已经发展。有许多自动化系统希望发送电子邮件但无法处理回复的实例，并且没有可用地址的“发件人：”字段对于此目的非常有用。
\n
它提供了以下示例：From: Automated System:;
然而，在同一部分的末尾，RFC 还说：
\n\n\n本文档建议目前不要在这些字段中普遍使用组语法
\n
在第 3 节中，RFC 阐明该From字段中的组语法仅供有限使用。
就我个人而言，我认为不应使用此方法\xe2\x80\x93\xc2\xa0，除非我们确定所有相关客户端都以其他方式显示原始域（从或Return-Path新标头重建）。否则，这将导致域身份验证（SPF、DKIM 和 DMARC）的所有努力失败。引入一个额外的标头字段，使客户端简单地隐藏回复按钮，对我来说似乎是更好的方法。
RFC 在第 5 节中对此方面进行了评论：
\n\n\n某些协议尝试通过将“发件人：”地址与特定的已验证域进行匹配来验证发起者地址（对于此类协议，请参阅作者域签名实践 (ADSP) 文档 [RFC5617]）。此类协议不适用于“发件人：”字段中缺少实际电子邮件地址（无论真实还是虚假）的邮件。本地策略将确定如何处理此类邮件，因此发件人需要注意在“发件人：”中使用组可能会对邮件的送达率产生不利影响。
\n
多么失败的机会\xe2\x80\xa6
\n| 归档时间： |
|
| 查看次数： |
11152 次 |
| 最近记录： |