这件事读得很好。

摘录：

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

这件事读得很好。

摘录：

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

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

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

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

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

小心这条线索中有一堆知识腐烂（以前是真的，现在不是了）。

为了避免在当前和未来世界以及世界任何地方对实际电子邮件地址的误报拒绝，您至少需要了解RFC 3490“应用程序中的域名国际化（IDNA）”的高级概念。我知道美国和A的人通常对此并不感兴趣，但它已经在世界各地广泛使用并迅速增加（主要是非英语为主的部分）。

要点是你现在可以像梅森一样使用地址@日本.com和wildwezyr@fahrvergn不，这还不能与现有的一切兼容（正如许多人在上面所感叹的那样，即使是简单的qmail样式+ident地址也经常被错误地拒绝）。但有一个RFC，有一个规范，它现在得到了IETF和ICANN的支持，而且更重要的是，目前有大量且越来越多的实现支持这种改进。

直到我搬回日本，开始看到像hei这样的电子邮件地址，我自己才对这一发展了解很多@やる.ca和Amazon URL如下：

http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/b/ref=topnav_storetab_e？即=UTF8&节点=3210981

我知道你不希望链接到规范，但如果你完全依赖互联网论坛上黑客的过时知识，你的电子邮件验证器最终会拒绝非英语用户越来越希望使用的电子邮件地址。对于这些用户来说，这种验证将与我们都讨厌的常见的脑死亡形式一样令人讨厌，这种形式无法处理一个+或三部分域名或其他任何东西。

所以我并不是说这不麻烦，但“在某些/任何/无条件下允许”的完整字符列表几乎是所有语言中的所有字符。如果你想“接受所有有效的电子邮件地址（也有许多无效的）”，那么你必须考虑IDN，这基本上使基于字符的方法变得无用（抱歉），除非你首先将国际化的电子邮件地址转换为Punycode（自2015年9月以来就已经过时了，以前是这样一种有效的替代方法）。

做完这些之后，你可以（大部分）遵循上面的建议。

答案是（几乎）全部（7位ASCII）。如果包含规则“…在某些/任何/无条件下允许…”

仅通过查看RFC 5322第17页顶部“域文本”部分中允许文本的几种可能包含规则之一，我们就可以发现：

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

本说明中仅有的三个缺失字符用于域文字[]中，以形成引号对\和空白字符（%d32）。使用整个范围32-126（十进制）。类似的要求显示为“qtext”和“ctext”。也允许/使用许多控制字符。RFC 5322第31页第4.1节中出现了一个此类控制字符列表，称为obs NO WS CTL。

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

如第3.5节开头所述，允许使用所有这些控制字符：

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

因此，这样的包含规则“过于宽泛”。或者，在其他意义上，预期规则“过于简单化”。

谷歌用他们的gmail.com地址做了一件有趣的事情。gmail.com地址只允许字母（a-z）、数字和句点（忽略）。

例如。，pikachu@gmail.com与pi.kachu@gmail.com，两个电子邮件地址将发送到同一邮箱。PIKACHU@gmail.com也发送到同一邮箱。

因此，要回答这个问题，有时取决于实现者希望遵循多少RFC标准。谷歌的gmail.com地址样式与标准兼容。他们这样做是为了避免不同的人使用类似的电子邮件地址时产生混淆。

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

维基百科链接是关于电子邮件地址通常允许的内容的一个很好的参考。http://en.wikipedia.org/wiki/Email_address