许多人已经试图回答这个问题。许多人也表示，许多答案已经过时。这是我的答案，就2022年的情况而言。

这个问题的答案显然不像提出的那么简单。当涉及到邮箱名称的命名时，所提出的标准（具体来说，在本文中为＜用户名＞），以及对这些RFC的解释非常多。

对于＜用户名＞部分，通用验收指导小组在这里的一个名为UASG-028的文档中提出了一个详细的指南，说明了电子邮件ID本地部分的组成。

对于<server>部分，此处提到的所有字符“应用程序的Unicode代码点和国际化域名（IDNA）”的字符状态为“PVALID”。此外，状态为“CONTEXTJ”和“CONTEXTO”的字符在某些上下文条件下有效。

这件事读得很好。

摘录：

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

维基百科对此有一篇很好的文章，官方规范在这里。来自Wikipdia：

电子邮件地址的本地部分可以使用以下任意ASCII字符：大写和小写英文字母（a-z，a-z）数字0至9字符！#$%&'*+-/=？^ _ `{ | } ~性格（点、句号、句号），前提是它不是第一个或最后一个字符，并且不连续出现两次或多次。此外，允许使用带引号的字符串（例如：“John Doe”@example.com），因此允许使用否则将被禁止的字符，但这些字符通常不会出现。RFC 5321还警告“希望接收邮件的主机应避免定义本地部分需要（或使用）引号字符串格式的邮箱”。

您可以从维基百科文章开始：

大写和小写英文字母（a-z，a-z）数字0至9字符！#$%&'*+-/=？^ _ `{ | } ~性格（点、句号、句号），前提是它不是第一个或最后一个字符，并且不连续出现两次或多次。

为了简单起见，我在验证前删除了双引号内的所有文本以及与双引号相关的文本，并根据不允许的内容对电子邮件地址提交进行了过滤。只是因为有人可以拥有约翰。。“$$hizzle*Bizzle”..Doe@whatever.com地址并不意味着我必须允许它进入我的系统。我们生活在这样一个未来，获得一个免费的电子邮件地址可能比做好擦屁股的工作花费更少的时间。而且，电子邮件标准似乎没有贴在输入的旁边，说明什么是允许的，什么是不允许的。

在删除引用的材料后，我还清理了各种RFC特别不允许的内容。特别禁止的字符和模式列表似乎是一个要测试的更短的列表。

不允许：

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

在给出的示例中：

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

在尝试添加或更改电子邮件地址时，向剩余结果发送确认电子邮件是查看代码是否能够处理提交的电子邮件地址的好方法。如果电子邮件在所需的多轮消毒后通过了验证，则进行确认。如果请求从确认链接返回，则新电子邮件可以从保留的||临时||炼狱状态或存储中移出，成为真正的、善意的一流存储电子邮件。

如果您想考虑周到，可以将电子邮件地址更改失败或成功的通知发送到旧电子邮件地址。未经确认的帐户设置可能会在合理的时间后完全失败，从而退出系统。

我不允许在我的系统上发送臭邮件，也许这只是在浪费钱。但是，99.9%的人只是做了正确的事情，并且有一封电子邮件不会利用边缘案例兼容性场景将符合性限制推到边缘。小心regex DDoS，这是一个你可能会遇到麻烦的地方。这与我做的第三件事有关，我对处理任何一封电子邮件的时间设置了限制。如果它需要降低我的机器的速度以获得验证——它无法通过我的传入数据API端点逻辑。

编辑：这个回答一直被指责为“糟糕”，也许这是理所应当的。也许它仍然糟糕，也许不是。

许多人已经试图回答这个问题。许多人也表示，许多答案已经过时。这是我的答案，就2022年的情况而言。

这个问题的答案显然不像提出的那么简单。当涉及到邮箱名称的命名时，所提出的标准（具体来说，在本文中为＜用户名＞），以及对这些RFC的解释非常多。

对于＜用户名＞部分，通用验收指导小组在这里的一个名为UASG-028的文档中提出了一个详细的指南，说明了电子邮件ID本地部分的组成。

对于<server>部分，此处提到的所有字符“应用程序的Unicode代码点和国际化域名（IDNA）”的字符状态为“PVALID”。此外，状态为“CONTEXTJ”和“CONTEXTO”的字符在某些上下文条件下有效。