RFC 822，3696和其他人指定电子邮件地址格式以及应如何验证这些格式。不幸的是，在实践中几乎没有人遵守它们，大多数开发人员倾向于动态发明一个正则表达式，或者从可疑来源复制粘贴一个以验证用户的电子邮件地址。实际上，这导致许多Web服务需要电子邮件地址，通常作为其用户的主要身份，但只接受RFC实际允许的非常有限的地址子集。
那么，对于通常被认为是“网络安全”电子邮件地址的当前状态，可以说些什么吗？是否有一些常见的子集随着时间的推移而逐渐被大多数服务所接受？ HTML 5 email输入类型的标准是什么，有望最终成为电子邮件的默认快速前端有效性检查？
请注意，我不是在询问应该做什么来验证电子邮件地址。理想情况下，验证应包括轻量级前端验证，它允许每个可能的地址和可能的一些误报，然后在后端使用实际的电子邮件服务器进行回调验证。我要问的是，对于当前在野外实施的内容是否有效，是否存在任何形式的共识。如果我要创建一个正则表达式来验证电子邮件地址（我不是，但幽默我），那么应该与其他人做什么大致匹配呢？如果我要在自己的服务器上为自己创建一个新的电子邮件地址，我应该坚持哪些安全子集才能在大多数网站上使用该地址？
答案 0 :(得分：0)
你在第一段中几乎回答了你自己的问题。
TL; DR没有达成共识。