跳至內容

電子郵件地址

維基百科，自由的百科全書
一個電子郵件地址的例子

電子郵件地址是發送電子郵件時用來標示電子郵箱的一串字符，也稱為電子郵箱地址或電子信箱地址。早期的電子郵件系統曾使用各種各樣的格式（英語：Non-Internet email address），但從1980年代起，隨着互聯網郵件系統標準的開發，到今天只保留了單一的格式。本條目使用的術語「電子郵件地址」指的是RFC 5322中定義的地址規範（addr-spec），而不是通常使用的地址；他們的區別是，「地址」可以包含顯示名稱和/或註釋。

一個電子郵件地址，比如[email protected]，由域內部分、@符號和大小寫不敏感的域名組成。雖然標準要求域內部分大小寫敏感，[1]但它又鼓勵接收主機以大小寫不敏感的方式發送消息。[2]例如，example.com的郵件系統將John.Smith與john.smith等同對待；某些郵件系統，例如Gmail，甚至將它們視為等同於johnsmith。[3]郵件系統往往限制其用戶對名稱的選擇，將其限定於一個技術上有效的字符集的子集內，在某些情況下甚至會對收件人地址作出限制。

隨着國際化域名的引入，也有人在為允許電子郵件地址中使用非ASCII字符而努力。

概述

電子郵件在互聯網上傳輸，使用的是簡單郵件傳輸協議（SMTP），這是由互聯網標準 RFC 5321 和 RFC 5322 及其擴展，如 RFC 6531 所定義的。用戶可以使用軟件，通過郵局協議（POP）或互聯網信息訪問協議（IMAP）來訪問和管理郵箱。這些軟件可以是運行在個人電腦、流動裝置上的電子郵件客戶端軟件，也可以是將消息呈現在屏幕上或打印輸出在紙上的Webmail系統。

電子郵件地址的通用格式為「域內部分@域」，例如[email protected]。一個地址由兩部分組成。@符號之前的部分（域內部分）標識郵箱的名稱，它往往是接收者的用戶名，例如jsmith。@符號之後的部分（域）是一個域名，代表郵箱的行政領域，例如一家公司的域名，example.com。

在傳遞郵件時，SMTP客戶端，例如郵件用戶代理（MUA）和消息傳輸代理（英語：Message transfer agent）（MTA），使用域名系統（DNS）來查找收件人域的資源記錄（RR）（電子郵件地址中@右邊的部分）；如果有郵件交換資源記錄（MX記錄），那麼返回的MX記錄中就會包含接收人郵件伺服器的名字, 否則SMTP客戶端就會使用地址記錄（A或AAAA）。然後MTA作為SMTP客戶端連接到這台伺服器。電子郵件地址的域內部分對中間郵件中繼系統來說並無意義，只有到了最終郵箱主機之後才有意義。電子郵件的發件人和中繼系統不能假定它是大小寫不敏感的，因為最終的郵箱主機既可以視之為大小寫敏感，也可以視之為大小寫不敏感。一個郵箱可能會收到多個電子郵件地址的郵件，如果管理員這樣配置的話。相反，一個電子郵件地址也可以是一個對應多個郵箱的發送列表的別名。電子郵件別名（英語：Email alias）、電子郵件列表、子地址和捕獲所有（英語：Email filtering）地址，即郵箱接收消息時不管域內部分，是幾種通用的模式，以實現投遞目標多樣化。

郵件交換器在遞送消息時，並不直接使用電子郵件消息頭字段中的地址。電子郵件消息還包着一個寫有郵件路由信息的消息信封。信封和頭地址可以相同，偽造的電子郵件地址常常出現在垃圾郵件、釣魚郵件和許多其它的基於互聯網的詐騙中。已經有很多倡議，想使這些偽造地址更易識別。

為了表明消息的接收者，電子郵件地址也可以有一個所關聯收件人的顯示名，而地址則放在後面的尖括號中，例如：John Smith <[email protected]>。

早期在互聯網之外其它網絡上的電子郵件地址（英語：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；
  • 除了字母與數字之外的可打印字符，!#$%&'*+-/=?^_`{|}~；
  • 點.，但不能作為首尾字符，也不能連續出現，若放在引號中則不受這些限制（例如[email protected]是不允許的，而"John..Doe"@example.com是允許的）。[6]

注意，某些郵件伺服器對域內部分使用通配符，比較典型的是跟在加號後面的字符，少數情況是跟在減號後面的字符，因此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所允許創建的電子郵件地址只能使用字母、數字、點（.）、下劃線（_）和連字符（-）。[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和[email protected](comment)都等同於[email protected]。

例子

有效的電子郵件地址
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]（有可能會去[email protected]收件箱，這取決於郵件伺服器）
[email protected]（域內部分只有一個字母）
[email protected]
admin@mailserver1（域名沒有頂級域，雖然ICANN強烈不建議無點的電子郵件地址）
[email protected]（參見互聯網頂級域列表）
" "@example.org（引號間有個空格）
"john..doe"@example.org（連續的兩個點是在引號內）
無效的電子郵件地址
Abc.example.com（沒有@字符）
A@b@[email protected]（在引號外只允許有一個@）
a"b(c)d,e:f;g<h>i[j\k][email protected]（域內部分所有的特殊字符，都不允許出現在引號外）
just"not"[email protected]（引號中的字符串必須是點分隔的，或者是組成域內部分的唯一元素）
this is"not\[email protected]（空格、引號和反斜線，只能存在於引號中，並且前面要有一個反斜線）
this\ still\"not\\[email protected]（即使在前面加了一個反斜線，空格、引號和反斜線仍然必須包含在引號中）
1234567890123456789012345678901234567890123456789012345678901234+x@example.com域內部分超過64個字符）
[email protected]（@之前有兩個連續的點）
[email protected]（@之後有兩個連續的點）

通用域內部分語義

根據 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。

子地址

某些郵件服務支持在域內部分包含一個標記，這樣該地址就是域內部分前綴的一個別名。例如，地址[email protected]表示與[email protected]相同的投遞地址。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]

在實踐中，某些網站的表單驗證會拒絕特殊的字符，比如在電子郵件地址中使用「+」，錯誤地將它們作為無效字符來處理。這可能會導致電子郵件被發送給錯誤的用戶，如果「+」被網站悄悄地刪掉而且沒有任何警告或錯誤信息的話。例如，打算發到用戶輸入的電子郵件地址[email protected]的電子郵件，可能會被錯誤地發送到[email protected]中。另一種情況是，如果網站的某些部分，比如用戶登記頁面，允許「+」字符，但其他部分，比如從網站的郵件列表中取消訂閱的頁面，並不允許，則可能會導致用戶體驗很差。

驗證和校驗

在網站驗證用戶身份時，常常會要求輸入電子郵件地址，以進行數據驗證（英語：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://zh.wikipedia.org/w/index.php?title=電子郵件地址&oldid=72958935"