答案是（几乎）全部（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 ....

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

这件事读得很好。

摘录：

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”的字符在某些上下文条件下有效。

如维基百科链接所示

电子邮件地址的本地部分可以使用以下任意ASCII字符：大写和小写拉丁字母A至Z和A至Z；数字0至9；特殊字符！#$%&'*+-/=^_`{|}~;点前提是除非被引用，否则它不是第一个或最后一个字符，并且除非被引用（例如。John..Doe@example.com不允许，但允许使用“John…Doe”@example.com）；空格和“（），：；<>@[\]字符允许有限制（它们只允许在带引号的字符串中，如下面的段落所述，此外，反斜杠或双引号前面必须有反斜杠）；注释允许在本地部分的两端加括号；例如john.smith（注释）@example.com和（注释）john.smith@example.com都相当于john.smith@example.com.除上述ASCII字符外，RFC 6531允许使用U+007F以上的国际字符（编码为UTF-8），尽管邮件系统可能会限制在分配本地部分时使用哪些字符。带引号的字符串可以作为点分隔的实体存在于本地部分中，或者当最外面的引号是本地部分的最外面的字符时（例如，abc.“defghi”.xyz@example.com或“abcdefghixyz”@example.com。相反，abc“defghi”xyz@example.com不是；abc\“def\”也不是ghi@example.com). 但是，引号字符串和字符并不常用。RFC 5321还警告“希望接收邮件的主机应避免定义本地部分需要（或使用）引号字符串格式的邮箱”。本地邮局主管会受到特殊对待，不区分大小写，应转发给域电子邮件管理员。从技术上讲，所有其他本地部件都区分大小写，因此jsmith@example.com和JSmith@example.com指定不同的邮箱；然而，许多组织将大小写字母视为等同字母。尽管在技术上有效的特殊字符范围很广；在实践中，组织、邮件服务、邮件服务器和邮件客户端通常不接受所有这些。例如，Windows Live Hotmail仅允许使用字母数字、点（.）、下划线（_）和连字符（-）创建电子邮件地址。常见的建议是避免使用一些特殊字符，以避免电子邮件被拒绝的风险。

请参阅RFC 5322：Internet消息格式，以及RFC 5321：简单邮件传输协议。

RFC 822也涵盖了电子邮件地址，但它主要涉及其结构：

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved
 
 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

和往常一样，维基百科有一篇关于电子邮件地址的文章：

电子邮件地址的本地部分可以使用以下任意ASCII字符：大写和小写拉丁字母A至Z和A至Z；数字0至9；特殊字符！#$%&'*+-/=^_`{|}~;点前提是除非被引用，否则它不是第一个或最后一个字符，并且除非被引用（例如。John..Doe@example.com不允许，但允许使用“John…Doe”@example.com）；空格和“（），：；<>@[\]字符允许有限制（它们只允许在带引号的字符串中，如下面的段落所述，此外，反斜杠或双引号前面必须有反斜杠）；注释允许在本地部分的两端加括号；例如john.smith（注释）@example.com和（注释）john.smith@example.com都相当于john.smith@example.com.

除ASCII字符外，截至2012年，您可以使用U+007F以上的国际字符，如RFC 6532规范所述，编码为UTF-8，并在维基百科上进行了解释。请注意，截至2019年，这些标准仍标记为“建议”，但正在缓慢推出。此规范中的更改基本上添加了国际字符作为有效的字母数字字符（atext），而不影响对允许和限制的特殊字符（如！#）的规则和@：。

有关验证，请参阅使用正则表达式验证电子邮件地址。

域部分定义如下：

协议的Internet标准（征求意见）要求组件主机名标签只能包含ASCII字母a到z（不区分大小写）、数字0到9和连字符（-）。RFC 952中主机名的原始规范规定，标签不能以数字或连字符开头，也不能以连字符结尾。然而，随后的规范（RFC 1123）允许主机名标签以数字开头。不允许使用其他符号、标点符号或空格。

检查@和。然后发送电子邮件让他们验证。

我仍然不能在互联网上20%的网站上使用我的.name电子邮件地址，因为有人搞砸了他们的电子邮件验证，或者因为它早于新地址的有效期。