电子邮件地址是发送电子邮件时用来标示电子邮箱的一串字符，也称为电子邮箱地址或电子信箱地址。早期的电子邮件系统曾使用，但从1980年代起，随着互联网邮件系统标准的开发，到今天只保留了单一的格式。本条目使用的术语“电子邮件地址”指的是RFC 5322中定义的地址规范（），而不是通常使用的地址；他们的区别是，“地址”可以包含显示名称和/或注释。
一个电子邮件地址，比如[email protected]，由域内部分、@符号和大小写不敏感的域名组成。虽然标准要求域内部分大小写敏感，但它又鼓励接收主机以大小写不敏感的方式发送消息。例如，example.com的邮件系统将John.Smith与john.smith等同对待；某些邮件系统，例如Gmail，甚至将它们视为等同于johnsmith。邮件系统往往限制其用户对名称的选择，将其限定于一个技术上有效的字符集的子集内，在某些情况下甚至会对收件人地址作出限制。
随着国际化域名的引入，也有人在为允许电子邮件地址中使用非ASCII字符而努力。
概述
电子邮件在因特网上传输，使用的是简单邮件传输协议（SMTP），这是由互联网标准 RFC 5321 和 RFC 5322 及其扩展，如 RFC 6531 所定义的。用户可以使用软件，通过邮局协议（POP）或因特网信息访问协议（IMAP）来访问和管理邮箱。这些软件可以是运行在个人电脑、移动设备上的电子邮件客户端软件，也可以是将消息呈现在屏幕上或打印输出在纸上的Webmail系统。
电子邮件地址的通用格式为“域内部分@域”，例如[email protected]。一个地址由两部分组成。@符号之前的部分（域内部分）标识邮箱的名称，它往往是接收者的用户名，例如jsmith。@符号之后的部分（域）是一个域名，代表邮箱的行政领域，例如一家公司的域名，example.com。
在传递邮件时，SMTP客户端，例如邮件用户代理（MUA）和（MTA），使用域名系统（DNS）来查找收件人域的资源记录（RR）（电子邮件地址中@右边的部分）；如果有邮件交换资源记录（MX记录），那么返回的MX记录中就会包含接收人邮件服务器的名字, 否则SMTP客户端就会使用地址记录（A或AAAA）。然后MTA作为SMTP客户端连接到这台服务器。电子邮件地址的域内部分对中间邮件中继系统来说并无意义，只有到了最终邮箱主机之后才有意义。电子邮件的发件人和中继系统不能假定它是大小写不敏感的，因为最终的邮箱主机既可以视之为大小写敏感，也可以视之为大小写不敏感。一个邮箱可能会收到多个电子邮件地址的邮件，如果管理员这样配置的话。相反，一个电子邮件地址也可以是一个对应多个邮箱的发送列表的别名。、电子邮件列表、子地址和地址，即邮箱接收消息时不管域内部分，是几种通用的模式，以实现投递目标多样化。
邮件交换器在递送消息时，并不直接使用电子邮件消息头字段中的地址。电子邮件消息还包着一个写有邮件路由信息的消息信封。信封和头地址可以相同，伪造的电子邮件地址常常出现在垃圾邮件、钓鱼邮件和许多其它的基于互联网的诈骗中。已经有很多倡议，想使这些伪造地址更易识别。
为了表明消息的接收者，电子邮件地址也可以有一个所关联收件人的显示名，而地址则放在后面的尖括号中，例如：John Smith 。
早期在形式，包括了其它一些标记，例如，要求的，以及UUCP的“”标记，这种地址是以消息中继时需要穿过的一系列计算机的形式给出的。这种形式被广泛地使用了好多年，但最终被互联网工程任务组（IETF）颁布的因特网标准所取代。
规则
电子邮件地址的格式是域内部分@域，其中域内部分最长为64个字符，而域名最长可达255个字符。正式的定义在 RFC 5322（3.2.3节和3.4.1节）和 RFC 5321 中——RFC 3696 中有一个可读性更强的形式及相关勘误表。注意，与 RFC 1034 和 RFC 1035 的规则不同，它的域名没有后面的点。
域内部分
电子邮件地址的域内部分可以使用以下任何ASCII字符：
- 大小写字母A到Z和a到z；
- 数字0到9；
- 除了字母与数字之外的可打印字符，!#$%&'*+-/=?^_`{|}~；
- 点.，但不能作为首尾字符，也不能连续出现，若放在引号中则不受这些限制（例如[email protected]是不允许的，而"John..Doe"@example.com是允许的）。
注意，某些邮件服务器对域内部分使用通配符，比较典型的是跟在加号后面的字符，少数情况是跟在减号后面的字符，因此fred+bah@domain和fred+foo@domain有可能指向同一个收件箱，fred+@domain可能也是一样，甚至fred@domain也可能一样。这可以用于标记电子邮件以达到分类的目的，见下文，及用于垃圾邮件控制。括号{和}也被用于这种方式，虽然较少。
- 空格和特殊字符"(),:;<>@[\]被允许有限制地使用（域内部分字符串必须放在引号中，后面的段落将会描述，并且，反斜杠或双引号之前，必须加一个反斜杠来转义）；
- 允许将注释放在小括号内，并放在域内部分的开头或结尾，例如john.smith(comment)@example.com和(comment)[email protected]都等同于[email protected]。
除上述ASCII字符之外，RFC 6531 还允许以UTF-8编码的U+007F以上的国际字符，但即使是支持SMTPUTF8和8BITMIME的邮件系统，在分配域内部分时也可能会限制使用的字符。
域内部分可以是用以点分隔的字符串，也可以是以引号包围的字符串，但不能两者都是。但是，以引号包围的字符串和字符并非常用的。RFC 5321 还警告说：“期望接受邮件的主机，应当避免将邮箱定义为：域内部分要求（或使用）以引号包围的字符串的形式”。
域内部分postmaster是被特殊对待的——它是大小写不敏感的，并且应当将发往该地址的邮件发送到该域的电子邮件管理员。技术上来讲，所有其它的域内部分都是大小写敏感的，因此[email protected]和[email protected]标识的是两个不同的邮箱；然而实际上，许多组织将大写字母与小写字母等同对待。事实上，RFC 5321 警告说：“期望接受邮件的主机，应当避免将邮箱定义为：……域内部分是大小写敏感的”。
尽管范围广泛的特殊字符在技术上是有效的，但在实践中，组织、邮件服务、邮件服务器和邮件客户端，往往并不能接受所有这些字符。例如，Hotmail所允许创建的电子邮件地址只能使用字母、数字、点（.）、下划线（_）和连字符（-）。通常的建议是，避免使用某些特殊字符，从而避免电子邮件被拒绝的风险。
域名
电子邮件地址的域名部分必须符合严格的规则：它必须满足对主机名的要求，一个以点分隔的DNS标签序列，每个标签被限定为长度不超过63个字符，且只能由下列字符组成：Gmail会忽略域内部分所有的点，以确定帐户的身分。这可以防止当账户your.username已经存在时，创建用户账户your.user.name或yourusername。
子地址
某些邮件服务支持在域内部分包含一个标记，这样该地址就是域内部分前缀的一个别名。例如，地址[email protected]表示与[email protected]相同的投递地址。RFC5233 将这种地址称为子地址（sub-addressing），但它也可以被称为加号地址（plus addressing）或标记地址（tagged addressing）。
这种形式的地址，在基本名称和标记之间可能会使用不同的分隔符，有不少电子邮件服务都支持，包括（加号）、Gmail（加号）、（加号）、Yahoo! Mail Plus（连字号）、苹果的iCloud（加号）、Outlook.com（加号）、ProtonMail（加号）、FastMail（加号和子域名地址）、（等号）、Qmail和（连字符）。Postfix还允许从合法字符集中任选一个字符配置作为分隔符。
这种标记的文本可用于过滤，
在实践中，某些网站的表单验证会拒绝特殊的字符，比如在电子邮件地址中使用“+”，错误地将它们作为无效字符来处理。这可能会导致电子邮件被发送给错误的用户，如果“+”被网站悄悄地删掉而且没有任何警告或错误信息的话。例如，打算发到用户输入的电子邮件地址[email protected]的电子邮件，可能会被错误地发送到[email protected]中。另一种情况是，如果网站的某些部分，比如用户登记页面，允许“+”字符，但其他部分，比如从网站的邮件列表中取消订阅的页面，并不允许，则可能会导致用户体验很差。
验证和校验
在网站验证用户身份时，常常会要求输入电子邮件地址，以进行。某些网站在进入时会验证电子邮件地址，通常会使用应用程序接口，但无法保证它能提供准确的结果。
识别电子邮件地址，通常要判断是否有两个部分以@连接。但是，RFC 822及后续RFC技术规范中说明得更加详细。用正则表达式可以检查所有这些标准，除了括号内的注释。
经过验证的语法上正确的电子邮件地址，并不能保证存在这样的电子邮箱。因此许多邮件服务器使用其它技术，并依靠相应的系统来检查邮箱是否存在。例如，通过域名系统来检查域名，或使用来检查邮箱是否存在。但是这种方式往往无法避免。
确保电子邮件地址是好的，需要结合各种验证技术。大型网站、批量邮件和垃圾邮件的发送者要求快速的算法，来预测电子邮件地址的有效性。这种方法严重依赖于启发式搜索和概率模型。
许多网站在评估电子邮件地址有效性时，与标准规范不同，会拒绝地址中包含某些有效字符，例如“+”和“/”，或限制其长度。RFC 3696提供了具体的建议，来验证因特网标识符，包括电子邮件地址。
许多浏览器已经实现了HTML5的表单，使得电子邮件地址的验证可以由浏览器来处理。
电子邮件地址国际化所允许的字符集，远远超出了当前许多验证算法所允许的字符集，例如所有U+0080以上的Unicode字符，以UTF-8编码。
身份验证
电子邮件地址是激活帐户的首要手段（在网站上进行用户识别和验证），但也可以用其它方法，如手机号码验证、邮政邮件验证、传真验证。用电子邮件地址验证时，网站通过电子邮件将一个特殊的临时超链发送到用户提供的电子邮件地址。用户在收到该邮件后，打开链接，帐户立即就被激活了。电子邮件地址也可以被网站用作转发消息的手段，例如，转发用户消息、用户操作到电子邮件收件箱。
国际化
IETF成立了一个技术和标准工作组，致力于电子邮件地址的国际化问题，称为“电子邮件地址国际化”（Email Address Internationalization，简称EAI）或“国际化邮件地址”（Internationalized Mail Address，简称IMA）。该工作组制定了 RFC 6530、RFC 6531、RFC 6532 和 RFC 6533，并继续为其它EAI相关的RFC而工作。
IETF的EAI工作组发布了 RFC 6530“国际化电子邮件概述与框架”，它使得在电子邮件地址的域内部分和域名中都可以使用非ASCII字符。RFC 6530为电子邮件提供的方案是基于UTF-8编码，该编码支持Unicode的所有字符。RFC 6531 为SMTP服务器提供了一种机制，以便在传输内容时进行沟通。
EAI的基本概念涉及了以UTF-8交换邮件。原始方案中还包含了对遗留系统向下兼容的机制，但现在它已经被丢弃。本地服务器负责地址的域内部分，而域名则会受到国际化域名规则的限制，尽管仍然以UTF-8发送。邮件服务器还需要负责在IMA形式和任意ASCII别名之间建立所有的映射机制。
EAI使用户可以有一个以母语表示的本地化地址，同时还有一个ASCII形式，以便与遗留系统通讯使用，或作为独立脚本使用。识别国际化域名和邮件地址的应用程序，必须具有转换这些表达方式的设备。
有些国家或地区预计会对这样的地址需求较大，比如中国、日本、俄罗斯，以及其它存在大量用户使用非基于拉丁文的书写系统的市场。
例如，2011年，印度政府在顶级域.in之外，批准了“.bharat”（表示Bhārat Gaṇarājya，即印度共和国）顶级域名，并以七种不同文字书写，以方便古吉拉特语、马拉地语、孟加拉语、泰米尔语、泰卢固语、旁遮普语和乌尔都语用户使用。印度公司XgenPlus.com声称其是世界上第一个EAI邮箱提供者，而现在为该邦每位公民提供免费的域名为राजस्थान.भारत的电子邮件帐户。一家领先的媒体公司拉贾斯坦杂志（Rajasthan Patrika）上线了他们的IDN域名पत्रिका.भारत及可用来联系的电子邮件。
国际化例子
基于RFC 5322的服务器不能处理以下例子中的地址，而RFC 6530则允许。兼容它的服务器能够处理这些地址：
- 带附加符号的拉丁字母：Pelé@example.com
- 希腊字母：δοκιμή@παράδειγμα.δοκιμή
- 繁体汉字：-{我買@屋企.香港}-
- 日文字符：
- 西里尔字母：чебурашка@ящик-с-апельсинами.рф
- 天城体文字：संपर्क@डाटामेल.भारत
国际化支持
- Postfix从2015年2月8日的稳定版3.0.0开始支持国际化邮件。
- Google支持向国际化域名发送电子邮件和从国际化域名接收邮件，但是不允许注册含有非ASCII字符的电子邮件地址。
- 微软在Outlook 2016中加入了类似的功能。
- DataMail在印度上线了国际化电子邮件支持，包括8种印度语言，使用XgenPlus电子邮件平台。
标准文件
- RFC 821——简单邮件传输协议（由RFC 2821取代）
- RFC 822——ARPA因特网文本消息格式标准（由RFC 2822取代）（勘误表）
- RFC 1035——域名及其实现与规范（勘误表）
- RFC 1123——对因特网主机、应用和支持的要求（由RFC 2821、RFC 5321更新）（勘误表）
- RFC 2142——通用服务、角色和功能的邮箱名称（勘误表）
- RFC 2821——简单邮件传输协议（取代RFC 821，更新RFC 1123，由RFC 5321取代）（勘误表）
- RFC 2822——因特网消息格式（取代RFC 822，由RFC 5322取代）（勘误表）
- RFC 3696——用于检查和名称转换的应用程序技术（勘误表）
- RFC 4291——IPv6的寻址架构（由RFC 5952更新）（勘误表）
- RFC 5321——简单邮件传输协议（取代RFC 2821，更新RFC 1123）（勘误表）
- RFC 5322——因特网消息格式（取代RFC 2822，更新RFC 6854）（勘误表）
- RFC 5952——关于IPv6地址的文本表示的建议（更新RFC 4291）（勘误表）
- RFC 6530——国际化电子邮件概述与框架（取代RFC 4952、5504、5825）
- RFC 6854——更新因特网消息格式，以允许在“发件人”头字段中使用分组语法（更新RFC 5322）
参见
- 反垃圾邮件技术
- 电子邮件客户端
- 电子邮箱
*
*
参考文献
*
*
*
评论 (0)