跳转到内容

電子郵件地址

维基百科，自由的百科全书
一个电子邮件地址的例子

电子邮件地址是发送电子邮件时用来标示电子邮箱的一串字符，也称为电子邮箱地址或电子信箱地址。早期的电子邮件系统曾使用各种各样的格式（英语：Non-Internet email address），但从1980年代起，随着互联网邮件系统标准的开发，到今天只保留了单一的格式。本条目使用的术语“电子邮件地址”指的是RFC 5322中定义的地址规范（addr-spec），而不是通常使用的地址；他们的区别是，“地址”可以包含显示名称和/或注释。

一个电子邮件地址，比如John.Smith@example.com，由域内部分、@符号和大小写不敏感的域名组成。虽然标准要求域内部分大小写敏感，[1]但它又鼓励接收主机以大小写不敏感的方式发送消息。[2]例如，example.com的邮件系统将John.Smith与john.smith等同对待；某些邮件系统，例如Gmail，甚至将它们视为等同于johnsmith。[3]邮件系统往往限制其用户对名称的选择，将其限定于一个技术上有效的字符集的子集内，在某些情况下甚至会对收件人地址作出限制。

随着国际化域名的引入，也有人在为允许电子邮件地址中使用非ASCII字符而努力。

概述

[编辑]

电子邮件在因特网上传输，使用的是简单邮件传输协议（SMTP），这是由互联网标准 RFC 5321 和 RFC 5322 及其扩展，如 RFC 6531 所定义的。用户可以使用软件，通过邮局协议（POP）或因特网信息访问协议（IMAP）来访问和管理邮箱。这些软件可以是运行在个人电脑、移动设备上的电子邮件客户端软件，也可以是将消息呈现在屏幕上或打印输出在纸上的Webmail系统。

电子邮件地址的通用格式为“域内部分@域”，例如jsmith@example.com。一个地址由两部分组成。@符号之前的部分（域内部分）标识邮箱的名称，它往往是接收者的用户名，例如jsmith。@符号之后的部分（域）是一个域名，代表邮箱的行政领域，例如一家公司的域名，example.com。

在传递邮件时，SMTP客户端，例如邮件用户代理（MUA）和消息传输代理（英语：Message transfer agent）（MTA），使用域名系统（DNS）来查找收件人域的资源记录（RR）（电子邮件地址中@右边的部分）；如果有邮件交换资源记录（MX记录），那么返回的MX记录中就会包含接收人邮件服务器的名字, 否则SMTP客户端就会使用地址记录（A或AAAA）。然后MTA作为SMTP客户端连接到这台服务器。电子邮件地址的域内部分对中间邮件中继系统来说并无意义，只有到了最终邮箱主机之后才有意义。电子邮件的发件人和中继系统不能假定它是大小写不敏感的，因为最终的邮箱主机既可以视之为大小写敏感，也可以视之为大小写不敏感。一个邮箱可能会收到多个电子邮件地址的邮件，如果管理员这样配置的话。相反，一个电子邮件地址也可以是一个对应多个邮箱的发送列表的别名。电子邮件别名（英语：Email alias）、电子邮件列表、子地址和捕获所有（英语：Email filtering）地址，即邮箱接收消息时不管域内部分，是几种通用的模式，以实现投递目标多样化。

邮件交换器在递送消息时，并不直接使用电子邮件消息头字段中的地址。电子邮件消息还包着一个写有邮件路由信息的消息信封。信封和头地址可以相同，伪造的电子邮件地址常常出现在垃圾邮件、钓鱼邮件和许多其它的基于互联网的诈骗中。已经有很多倡议，想使这些伪造地址更易识别。

为了表明消息的接收者，电子邮件地址也可以有一个所关联收件人的显示名，而地址则放在后面的尖括号中，例如：John Smith <john.smith@example.org>。

早期在因特网之外其它网络上的电子邮件地址（英语：Non-Internet email address）形式，包括了其它一些标记，例如，X.400（英语：X.400）要求的，以及UUCP的“叹号路径（英语：Bang path）”标记，这种地址是以消息中继时需要穿过的一系列计算机的形式给出的。这种形式被广泛地使用了好多年，但最终被互联网工程任务组（IETF）颁布的因特网标准所取代。

规则

[编辑]

电子邮件地址的格式是域内部分@域，其中域内部分最长为64个字符，而域名最长可达255个字符。[4]正式的定义在 RFC 5322（3.2.3节和3.4.1节）和 RFC 5321 中——RFC 3696 中有一个可读性更强的形式[5]及相关勘误表。注意，与 RFC 1034 和 RFC 1035 的规则不同，它的域名没有后面的点。

域内部分

[编辑]

电子邮件地址的域内部分可以使用以下任何ASCII字符：

  • 大小写拉丁（英语：Basic Latin (Unicode block)）字母A到Z和a到z；
  • 数字0到9；
  • 除了字母与数字之外的可打印字符，!#$%&'*+-/=?^_`{|}~；
  • 点.，但不能作为首尾字符，也不能连续出现，若放在引号中则不受这些限制（例如John..Doe@example.com是不允许的，而"John..Doe"@example.com是允许的）。[6]

注意，某些邮件服务器对域内部分使用通配符，比较典型的是跟在加号后面的字符，少数情况是跟在减号后面的字符，因此fred+bah@domain和fred+foo@domain有可能指向同一个收件箱，fred+@domain可能也是一样，甚至fred@domain也可能一样。这可以用于标记电子邮件以达到分类的目的，见下文，及用于垃圾邮件控制。括号{和}也被用于这种方式，虽然较少。

  • 空格和特殊字符"(),:;<>@[\]被允许有限制地使用（域内部分字符串必须放在引号中，后面的段落将会描述，并且，反斜杠或双引号之前，必须加一个反斜杠来转义）；
  • 允许将注释放在小括号内，并放在域内部分的开头或结尾，例如john.smith(comment)@example.com和(comment)john.smith@example.com都等同于john.smith@example.com。

除上述ASCII字符之外，RFC 6531 还允许以UTF-8编码的U+007F以上的国际字符，但即使是支持SMTPUTF8和8BITMIME的邮件系统，在分配域内部分时也可能会限制使用的字符。

域内部分可以是用以点分隔的字符串，也可以是以引号包围的字符串，但不能两者都是。但是，以引号包围的字符串和字符并非常用的。RFC 5321 还警告说：“期望接受邮件的主机，应当避免将邮箱定义为：域内部分要求（或使用）以引号包围的字符串的形式”。

域内部分postmaster是被特殊对待的——它是大小写不敏感的，并且应当将发往该地址的邮件发送到该域的电子邮件管理员。技术上来讲，所有其它的域内部分都是大小写敏感的，因此jsmith@example.com和JSmith@example.com标识的是两个不同的邮箱；然而实际上，许多组织将大写字母与小写字母等同对待。事实上，RFC 5321 警告说：“期望接受邮件的主机，应当避免将邮箱定义为：……域内部分是大小写敏感的”。

尽管范围广泛的特殊字符在技术上是有效的，但在实践中，组织、邮件服务、邮件服务器和邮件客户端，往往并不能接受所有这些字符。例如，Hotmail所允许创建的电子邮件地址只能使用字母、数字、点（.）、下划线（_）和连字符（-）。[7]通常的建议是，避免使用某些特殊字符，从而避免电子邮件被拒绝的风险。[8]

域名

[编辑]

电子邮件地址的域名部分必须符合严格的规则：它必须满足对主机名的要求，一个以点分隔的DNS标签序列，每个标签被限定为长度不超过63个字符，且只能由下列字符组成：[6]:§2

  • 大小写拉丁字母A到Z和a到z；
  • 数字0到9，但顶级域名不能是纯数字；
  • 连字符-，但不能作为首尾字符。

该规则也被称为“LDH规则”（Letters, Digits, Hyphen，即字母、数字、连字符）。此外，该域也可以是一个包以方括号[]的IP地址的形式，例如jsmith@[192.168.2.1]或jsmith@[IPv6:2001:db8::1]。但是除了垃圾邮件，这很少见。国际化域名（会被编码，以遵守主机名的要求）允许使用非ASCII字符的域。在符合 RFC 6531 和 RFC 6532 的邮件系统中，电子邮件地址可以用UTF-8来编码，域内部分和域名都可以。

域名和域内部分一样，可以包含注释；例如，john.smith@(comment)example.com和john.smith@example.com(comment)都等同于john.smith@example.com。

例子

[编辑]
有效的电子邮件地址
simple@example.com
very.common@example.com
disposable.style.email.with+symbol@example.com
other.email-with-hyphen@example.com
fully-qualified-domain@example.com
user.name+tag+sorting@example.com（有可能会去user.name@example.com收件箱，这取决于邮件服务器）
x@example.com（域内部分只有一个字母）
example-indeed@strange-example.com
admin@mailserver1（域名没有顶级域，虽然ICANN强烈不建议无点的电子邮件地址）
example@s.example（参见互联网顶级域列表）
" "@example.org（引号间有个空格）
"john..doe"@example.org（连续的两个点是在引号内）
无效的电子邮件地址
Abc.example.com（没有@字符）
A@b@c@example.com（在引号外只允许有一个@）
a"b(c)d,e:f;g<h>i[j\k]l@example.com（域内部分所有的特殊字符，都不允许出现在引号外）
just"not"right@example.com（引号中的字符串必须是点分隔的，或者是组成域内部分的唯一元素）
this is"not\allowed@example.com（空格、引号和反斜线，只能存在于引号中，并且前面要有一个反斜线）
this\ still\"not\\allowed@example.com（即使在前面加了一个反斜线，空格、引号和反斜线仍然必须包含在引号中）
1234567890123456789012345678901234567890123456789012345678901234+x@example.com域内部分超过64个字符）
john..doe@example.com（@之前有两个连续的点）
john.doe@example..com（@之后有两个连续的点）

通用域内部分语义

[编辑]

根据 RFC 5321 2.3.11“邮箱及地址”，“……只有指定在地址的域中的主机，才能解读和分配域内部分的语义。”（“……the local-part MUST be interpreted and assigned semantics only by the host specified in the domain of the address.”）这意味着，对另一台邮件服务器的域内部分的含义，不能作出任何假设。这完全取决于该邮件服务器的配置。

域内部分正规化

[编辑]

对电子邮件地址“域内部分”的解释，依赖于邮件服务器所实现的惯例和策略。例如，大小写敏感性可以用来区分不同的邮箱，因此域内部分的字符只使用大写，虽然这不是很常见。[9]Gmail会忽略域内部分所有的点，以确定帐户的身分。[10]这可以防止当账户your.username已经存在时，创建用户账户your.user.name或yourusername。

子地址

[编辑]

某些邮件服务支持在域内部分包含一个标记，这样该地址就是域内部分前缀的一个别名。例如，地址joeuser+tag@example.com表示与joeuser@example.com相同的投递地址。RFC5233 将这种地址称为子地址（sub-addressing），但它也可以被称为加号地址（plus addressing）或标记地址（tagged addressing）。

这种形式的地址，在基本名称和标记之间可能会使用不同的分隔符，有不少电子邮件服务都支持，包括Runbox（英语：Runbox）（加号）、Gmail（加号）、[11]Rackspace Email（英语：Rackspace Email）（加号）、Yahoo! Mail Plus（连字号）、[12]苹果的iCloud（加号）、Outlook.com（加号）、[13]ProtonMail（加号）、[14]FastMail（加号和子域名地址）、[15]MMDF（英语：MMDF）（等号）、Qmail和信使邮件服务器（英语：Courier Mail Server）（连字符）。[16][17]Postfix还允许从合法字符集中任选一个字符配置作为分隔符。[18]

这种标记的文本可用于过滤，[16]或创建一次性电子邮件地址（英语：Disposable email address）。[19]

在实践中，某些网站的表单验证会拒绝特殊的字符，比如在电子邮件地址中使用“+”，错误地将它们作为无效字符来处理。这可能会导致电子邮件被发送给错误的用户，如果“+”被网站悄悄地删掉而且没有任何警告或错误信息的话。例如，打算发到用户输入的电子邮件地址foo+bar@example.com的电子邮件，可能会被错误地发送到foobar@example.com中。另一种情况是，如果网站的某些部分，比如用户登记页面，允许“+”字符，但其他部分，比如从网站的邮件列表中取消订阅的页面，并不允许，则可能会导致用户体验很差。

验证和校验

[编辑]

在网站验证用户身份时，常常会要求输入电子邮件地址，以进行数据验证（英语：Data validation）。某些网站在进入时会验证电子邮件地址，通常会使用应用程序接口，但无法保证它能提供准确的结果。[20]

识别电子邮件地址，通常要判断是否有两个部分以@连接。但是，RFC 822及后续RFC技术规范中说明得更加详细。[21]用正则表达式可以检查所有这些标准，除了括号内的注释。[22]

经过验证的语法上正确的电子邮件地址，并不能保证存在这样的电子邮箱。因此许多邮件服务器使用其它技术，并依靠相应的系统来检查邮箱是否存在。例如，通过域名系统来检查域名，或使用回调校验（英语：Callback verification）来检查邮箱是否存在。但是这种方式往往无法避免目录收割攻击（英语：Directory Harvest Attack）。

确保电子邮件地址是好的，需要结合各种验证技术。大型网站、批量邮件和垃圾邮件的发送者要求快速的算法，来预测电子邮件地址的有效性。这种方法严重依赖于启发式搜索和概率模型。[23]

许多网站在评估电子邮件地址有效性时，与标准规范不同，会拒绝地址中包含某些有效字符，例如“+”和“/”，或限制其长度。RFC 3696提供了具体的建议，来验证因特网标识符，包括电子邮件地址。

许多浏览器已经实现了HTML5的表单，使得电子邮件地址的验证可以由浏览器来处理。[24]

电子邮件地址国际化所允许的字符集，远远超出了当前许多验证算法所允许的字符集，例如所有U+0080以上的Unicode字符，以UTF-8编码。

身份验证

[编辑]

电子邮件地址是激活帐户的首要手段（在网站上进行用户识别和验证），但也可以用其它方法，如手机号码验证、邮政邮件验证、传真验证。用电子邮件地址验证时，网站通过电子邮件将一个特殊的临时超链发送到用户提供的电子邮件地址。用户在收到该邮件后，打开链接，帐户立即就被激活了。电子邮件地址也可以被网站用作转发消息的手段，例如，转发用户消息、用户操作到电子邮件收件箱。

国际化

[编辑]

IETF成立了一个技术和标准工作组，致力于电子邮件地址的国际化问题，称为“电子邮件地址国际化”（Email Address Internationalization，简称EAI）或“国际化邮件地址”（Internationalized Mail Address，简称IMA）。[25]该工作组制定了 RFC 6530、RFC 6531、RFC 6532 和 RFC 6533，并继续为其它EAI相关的RFC而工作。

IETF的EAI工作组发布了 RFC 6530“国际化电子邮件概述与框架”，它使得在电子邮件地址的域内部分和域名中都可以使用非ASCII字符。RFC 6530为电子邮件提供的方案是基于UTF-8编码，该编码支持Unicode的所有字符。RFC 6531 为SMTP服务器提供了一种机制，以便在传输SMTPUTF8（英语：Extended SMTP#SMTPUTF8）内容时进行沟通。

EAI的基本概念涉及了以UTF-8交换邮件。原始方案中还包含了对遗留系统向下兼容的机制，但现在它已经被丢弃。[26]本地服务器负责地址的域内部分，而域名则会受到国际化域名规则的限制，尽管仍然以UTF-8发送。邮件服务器还需要负责在IMA形式和任意ASCII别名之间建立所有的映射机制。

EAI使用户可以有一个以母语表示的本地化地址，同时还有一个ASCII形式，以便与遗留系统通讯使用，或作为独立脚本使用。识别国际化域名和邮件地址的应用程序，必须具有转换这些表达方式的设备。

有些国家或地区预计会对这样的地址需求较大，比如中国、日本、俄罗斯，以及其它存在大量用户使用非基于拉丁文的书写系统的市场。

例如，2011年，印度政府在顶级域.in之外，批准了“.bharat”（表示Bhārat Gaṇarājya，即印度共和国）顶级域名，并以七种不同文字书写，[27][28][29]以方便古吉拉特语、马拉地语、孟加拉语、泰米尔语、泰卢固语、旁遮普语和乌尔都语用户使用。印度公司XgenPlus.com声称其是世界上第一个EAI邮箱提供者，[30]而拉贾斯坦邦政府（英语：Government of Rajasthan）现在为该邦每位公民提供免费的域名为राजस्थान.भारत的电子邮件帐户。[31]一家领先的媒体公司拉贾斯坦杂志（Rajasthan Patrika）上线了他们的IDN域名पत्रिका.भारत及可用来联系的电子邮件。

国际化例子

[编辑]

基于RFC 5322的服务器不能处理以下例子中的地址，而RFC 6530则允许。兼容它的服务器能够处理这些地址：

国际化支持

[编辑]
  • Postfix代理（英语：Message transfer agent）从2015年2月8日的稳定版3.0.0开始支持国际化邮件。[32]
  • Google支持向国际化域名发送电子邮件和从国际化域名接收邮件，但是不允许注册含有非ASCII字符的电子邮件地址。[33]
  • 微软在Outlook 2016中加入了类似的功能。[34]
  • DataMail在印度上线了国际化电子邮件支持，包括8种印度语言，使用XgenPlus电子邮件平台。[35]

标准文件

[编辑]
  • 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）

参见

[编辑]

参考文献

[编辑]
  1. ^ J. Klensin. General Syntax Principles and Transaction Model[通用语法规则与事务模型]. Simple Mail Transfer Protocol. 2008-10: p. 15. sec. 2.4. RFC 5321 （英文）. The local-part of a mailbox MUST BE treated as case sensitive.[邮箱的域内部分必须按大小写敏感处理。] 
  2. ^ J. Klensin. General Syntax Principles and Transaction Model[通用语法规则与事务模型]. Simple Mail Transfer Protocol. 2008-10: p. 15. sec. 2.4. RFC 5321 （英文）. However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.[然而，邮箱域内部分的大小写敏感性阻碍了互通性，因此不建议这样做。] 
  3. ^ 收到他人的邮件. Google. [2019-01-03]. （原始内容存档于2021-05-05）. 如果发件人在您的电子邮件地址中添加了点，您仍会收到该电子邮件。 
  4. ^ RFC 5321
  5. ^ 作者为J. Klensin，与RFC 5321的作者相同
  6. ^ 6.0 6.1 RFC 3696:§3
  7. ^ 创建帐户. [2019-01-17]. 
  8. ^ Characters in the local part of an email address [电子邮件地址域内部分中的字符]. [2016-03-30]. （原始内容存档于2021-05-06） （英语）. 
  9. ^ Heinz Tschabitscher. Are Email Addresses Case Sensitive? [电子邮件地址是大小写敏感的吗？]. [2019-01-03]. （原始内容存档于2016-06-03） （英语）. 
  10. ^ 收到他人的邮件. Google. [2019-02-23]. （原始内容存档于2011-06-08）. 
  11. ^ 通过其他地址或别名发送电子邮件. Google. [2019-02-23]. （原始内容存档于2019-08-30）. 
  12. ^ Disposable addresses in Yahoo Mail - Yahoo Help - SLN3523 [Yahoo Mail中的一次性地址 - Yahoo帮助 - SLN3523]. [2019-02-23]. （原始内容存档于2020-11-11） （英语）. 
  13. ^ Outlook.com supports simpler "+" email aliases too [Outlook.com也支持简单的“+”电子邮件别名]. Within Windows. （原始内容存档于2014-02-20） （英语）. 
  14. ^ Addresses and Aliases [地址与别名]. ProtonMail. [2019-01-03]. （原始内容存档于2017-07-12） （英语）. 
  15. ^ Plus addressing and subdomain addressing [加号地址和子域名地址]. FastMail. [2019-01-03]. （原始内容存档于2020-10-06） （英语）. 
  16. ^ 16.0 16.1 Dot-Qmail, Control the delivery of mail messages [点-Qmail，控制邮件消息的递送]. [2012-01-27]. （原始内容存档于2012-01-26） （英语）. 
  17. ^ Sill, Dave. 4.1.5. extension addresses [4.1.5. 扩展地址]. Life with qmail. [2012-01-27]. （原始内容存档于2012-02-29） （英语）. 
  18. ^ Postfix Configuration Parameters [Postfix配置参数]. Postfix. [2019-01-03]. （原始内容存档于2008-11-21） （英语）. 
  19. ^ Gina Trapani. Instant disposable Gmail addresses [方便的一次性Gmail地址]. 2005 [2019-01-03]. （原始内容存档于2019-01-13） （英语）. 
  20. ^ Paul, Andrew. When a Valid and Deliverable Email is Neither Valid nor Deliverable [当有效且可投递的电子邮件既无效也无法投递时]. Email Answers. [2013-04-26]. （原始内容存档于2013-05-01） （英语）. 
  21. ^ I Knew How To Validate An Email Address Until I Read The RFC [直到我读了RFC，我才知道如何验证电子邮件地址]. [2019-01-03]. （原始内容存档于2021-02-05） （英语）. 
  22. ^ Mail::RFC822::Address [邮件::RFC822::地址]. [2019-01-03]. （原始内容存档于2021-05-12） （英语）. 
  23. ^ Jan Hornych. Verification & Validation Techniques for Email Address Quality Assurance [保证电子邮件地址质量的校验和验证技术] (PDF). 牛津大学. 2011 [2019-01-03]. （原始内容 (PDF)存档于2020-10-29） （英语）. 
  24. ^ 4.10 Forms — HTML5 [4.10 表单 — HTML5]. W3C. [2019-01-03]. （原始内容存档于2019-06-25） （英语）. 
  25. ^ Eai Status Pages [EAI状态页]. 电子邮件地址国际化（活跃的工作组）. IETF. 2013-03-18 [2008-07-26]. （原始内容存档于2021-05-17） （英语）. 
  26. ^ Email Address Internationalization (eai) [电子邮件地址国际化（EAI）]. IETF. [2010-11-30]. （原始内容存档于2021-05-09） （英语）. 
  27. ^ 2011-01-25 - Approval of Delegation of the seven top-level domains representing India in various languages - myICANN.org [2011-01-25 - 代表印度各种语言的七个顶级域获批 - myICANN.org]. [2019-01-03]. （原始内容存档于2020-10-28） （英语）. 
  28. ^ Internationalized Domain Names (IDNs) | Registry.In [国际化域名（IDN） | Registry.In]. [2016-10-17]. （原始内容存档于2016-05-13） （英语）. 
  29. ^ Now, get your email address in Hindi - The Economic Times [现在，取得您的印地语电子邮件地址 - 经济时代]. 经济时代（英语：The Economic Times）. [2016-10-17]. （原始内容存档于2016-08-28） （英语）. 
  30. ^ Universal Acceptance in India [在印度普遍接受]. [2019-01-03]. （原始内容存档于2021-01-24） （英语）. 
  31. ^ देश में पहला, प्रदेश के हर नागरिक के लिए मुफ्त ई-वॉल्ट और ई-मेल की सुविधा शुरू - वसुन्धरा राजे [CM上线了该邦每位公民都可免费使用的电子邮件和电子银行]. वसुन्धरा राजे. 2017-08-18 [2017-08-20]. （原始内容存档于2020-10-23） （印地语）. 
  32. ^ 'Postfix stable release 3.0.0' – MARC ['Postfix稳定版3.0.0' – MARC]. marc.info. [2019-01-03]. （原始内容存档于2019-07-25） （英语）. 
  33. ^ A first step toward more global email [朝向更加全球化的电子邮件迈进的第一步]. Google. [2014-08-06]. （原始内容存档于2017-07-02） （英语）. 
  34. ^ What's new in Outlook 2016 for Windows [Windows版Outlook 2016有哪些新功能]. support.office.com. [2019-01-03]. （原始内容存档于2018-05-18） （英语）. 
  35. ^ DataMail launches free linguistic email service in eight Indian languages [DataMail上线了免费的覆盖八种印度语言的电子邮件服务]. [2017-11-25]. （原始内容存档于2020-10-24） （英语）. 
检索自“https://zh1.bitforum.be.eu.org/w/index.php?title=電子郵件地址&oldid=72958935”