電子郵件地址

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

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

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

## 概述

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

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

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

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

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

早期在網際網路之外其它網絡上的電子郵件地址形式，包括了其它一些標記，例如，X.400 要求的，以及 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`；
* 除了字母與數字之外的可列印字符，`!#$%&'*+-/=?^_`{|}~`；
* 點 `.`，但不能作為首尾字符，也不能連續出現，若放在引號中則不受這些限制（例如 `John..Doe@example.com` 是不允許的，而 `"John..Doe"@example.com` 是允許的）。

注意，某些郵件伺服器對域內部分使用通配符，比較典型的是跟在加號後面的字符，少數情況是跟在減號後面的字符，因此 `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 所允許創建的電子郵件地址只能使用字母、數字、點（`.`）、下劃線（`_`）和連字符（`-`）。通常的建議是，避免使用某些特殊字符，從而避免電子郵件被拒絕的風險。

### 域名

電子郵件地址的域名部分必須符合嚴格的規則：它必須滿足對主機名的要求，一個以點分隔的 DNS 標籤序列，每個標籤被限定為長度不超過 63 個字符，且只能由下列字符組成：

* 大小寫拉丁字母 `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.」）這意味著，對另一台郵件伺服器的域內部分的含義，不能作出任何假設。這完全取決於該郵件伺服器的配置。

### 域內部分正規化

對電子郵件地址「域內部分」的解釋，依賴於郵件伺服器所實現的慣例和策略。例如，大小寫敏感性可以用來區分不同的郵箱，因此域內部分的字符只使用大寫，雖然這不是很常見。Gmail 會忽略域內部分所有的點，以確定帳戶的身分。這可以防止當帳戶 your.username 已經存在時，創建用戶帳戶 your.user.name 或 yourusername。

### 子地址

某些郵件服務支持在域內部分包含一個標記，這樣該地址就是域內部分前綴的一個別名。例如，地址 joeuser+tag@example.com 表示與 joeuser@example.com 相同的投遞地址。RFC5233 將這種地址稱為子地址（sub-addressing），但它也可以被稱為加號地址（plus addressing）或標記地址（tagged addressing）。

這種形式的地址，在基本名稱和標記之間可能會使用不同的分隔符，有不少電子郵件服務都支持，包括 Runbox（加號）、Gmail（加號）、Rackspace Email（加號）、Yahoo! Mail Plus（連字號）、蘋果的 iCloud（加號）、Outlook.com（加號）、ProtonMail（加號）、FastMail（加號和子域名地址）、MMDF（等號）、Qmail 和信使郵件伺服器（連字符）。Postfix 還允許從合法字符集中任選一個字符配置作為分隔符。

這種標記的文本可用於過濾，或創建一次性電子郵件地址。

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

## 驗證和校驗

在網站驗證用戶身份時，常常會要求輸入電子郵件地址，以進行數據驗證。某些網站在進入時會驗證電子郵件地址，通常會使用應用程式接口，但無法保證它能提供準確的結果。

識別電子郵件地址，通常要判斷是否有兩個部分以 @連接。但是，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 伺服器提供了一種機制，以便在傳輸 SMTPUTF8 內容時進行溝通。

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）

## 參見

* 反垃圾郵件技術
* 電子郵件客戶端
* 電子郵箱
* 電子郵件認證
* 國際電子郵件

## 參考文獻

* 維基教科書中有關驗證電子郵件地址的文本
* 維基教科書中有關最佳實踐的文本
* 維基共享資源上的相關多媒體資源：電子郵件地址