历史上，为什么电子邮件地址的RFC（请求评论）变得如此复杂？

Question

RFC 5321, 5322和6531对验证电子邮件地址有复杂的规则。它们：

• 允许在电子邮件地址中添加注释
• 提供了对符号的复杂限制规则："() ,:;<>@[\]
• 将postmaster本地部分视为不区分大小写，但所有其他部分均区分大小写
• 允许一组电子邮件地址

由于这些复杂的规则，仅使用正则表达式无法测试给定字符串是否符合RFC中电子邮件地址的语法有效性（无法执行）。

显然，许多主要电子邮件提供商不支持这些规则。

历史上，为什么要创建如此复杂的电子邮件地址规则？维基百科关于电子邮件起源的文章似乎暗示，早在1980年代初期，现代标准就旨在涵盖所有遗留的电子邮件系统及其特定的标准和语法。

然而，标准实施者、电子邮件提供商和电子邮件最终用户都对工作系统有着切实的利益，当规则不太深奥且可以轻松转换为通过有限数量的测试的软件时，这一目标更易实现。那么，为什么我们今天拥有一个如此复杂的标准，却没有人完全使用它呢？

同样是历史问题，XML 在很大程度上已被 JSON 取代，其成功部分归功于其语法的简单性。

- Andrei Botalov

---

因为 RFC 应该涵盖所有边缘情况，而不仅仅是“主要提供者”？ - ceejayoz

我认为这是一个明智且合理的问题，应该借助历史视角进行深入讨论。上述提到的RFC文档并不是唯一的罪犯；控制IP地址转录方式的RFC文档同样复杂难懂。有趣的是，在现实世界中，只有极小部分RFC文档被积极使用——几乎所有的电子邮件地址都长成这个模样 [e-mail]，所有的IP地址也都是像 123.234.231.132 这样。如果这个问题没有过早关闭，我们现在可以畅所欲言地讨论这些高度复杂的RFC文档的优缺点和历史背景了。 - flow

虽然这是一个有趣且在更广泛的软件社区中是有效的问题，但它并不适合在StackOverflow上提问。 - JasonMArcher

我反对：这是一个讨论编程问题的网站。有时候了解一些历史背景很有好处——为什么事情会变成现在这个样子。这也是一个非常实际的问题，即：虽然电子邮件地址在理论上具有极其复杂的语法，但在实际应用中通常会简化为更简单的版本。这里是讨论这个问题的地方。 - flow

Stackoverflow在处理这些问题方面特别糟糕。也许可以在相关的邮件列表上提问。 - Marcin

最近有消息称，netmask npm包在过去的10年中没有正确处理八进制IPv4地址表示法，这是一个漏洞。我完全忘记了IPv4地址可以用八进制写，因为每个人都使用十进制。我想知道为什么有人认为这种不必要的复杂性是一个好主意... - Andy

Answer 1

唯一确定检查给定电子邮件地址是否真实的方法是向其发送电子邮件并查看用户是否收到。可以对地址执行的唯一有用检查是检查电子邮件地址的语法是否有效。这就是该模块所做的。

发送邮件的系统必须能够处理所有有效地址的出站邮件。与相关标准相反，一些有缺陷的系统将某些合法地址视为无效，并未能处理发送到这些地址的邮件。例如，Hotmail拒绝发送任何包含以下任何标准允许字符的地址：!#$%*/?^`{|}~

不同级别的标准，一些非常严格，因此复杂。

- Sully

---

虽然您的答案从技术上讲是正确的，但并没有回答问题（问题是关于电子邮件地址的语法）。知道街道地址是否符合语法是一回事，知道该位置上是否有建筑物是另一回事。 - flow