Can you summarize the following document?
        
  電子郵件在因特網上傳輸,使用的是簡單郵件傳輸協議(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)頒佈的因特網標準所取代。

  電子郵件地址的格式是codice_1,其中域內部分最長為64個字元,而域名最長可達255個字元。正式的定義在 RFC 5322(3.2.3節和3.4.1節)和 RFC 5321 中——RFC 3696 中有一個可讀性更強的形式及相關勘誤表。注意,與 RFC 1034 和 RFC 1035 的規則不同,它的域名沒有後面的點。

  電子郵件地址的域內部分可以使用以下任何ASCII字元:  注意,某些郵件伺服器對域內部分使用萬用字元,比較典型的是跟在加號後面的字元,少數情況是跟在減號後面的字元,因此codice_12和codice_13有可能指向同一個收件箱,codice_14可能也是一樣,甚至codice_15也可能一樣。這可以用於標記電子郵件以達到分類的目的,見下文,及用於垃圾郵件控制。括號codice_16和codice_17也被用於這種方式,雖然較少。  除上述ASCII字元之外,RFC 6531 還允許以UTF-8編碼的U+007F以上的國際字元,但即使是支援SMTPUTF8和8BITMIME的郵件系統,在分配域內部分時也可能會限制使用的字元。  域內部分可以是用以點分隔的字串,也可以是以引號包圍的字串,但不能兩者都是。但是,以引號包圍的字串和字元並非常用的。RFC 5321 還警告說:“期望接受郵件的主機,應當避免將郵箱定義為:域內部分要求(或使用)以引號包圍的字串的形式”。  域內部分codice_22是被特殊對待的——它是大小寫不敏感的,並且應當將發往該地址的郵件傳送到該域的電子郵件管理員。技術上來講,所有其它的域內部分都是大小寫敏感的,因此codice_23和codice_24標識的是兩個不同的郵箱;然而實際上,許多組織將大寫字母與小寫字母等同對待。事實上,RFC 5321 警告說:“期望接受郵件的主機,應當避免將郵箱定義為:......域內部分是大小寫敏感的”。  儘管範圍廣泛的特殊字元在技術上是有效的,但在實踐中,組織、郵件服務、郵件伺服器和郵件客戶端,往往並不能接受所有這些字元。例如,Hotmail所允許建立的電子郵件地址只能使用字母、數字、點(codice_9)、下劃線(codice_26)和連字元(codice_27)。通常的建議是,避免使用某些特殊字元,從而避免電子郵件被拒絕的風險。

  電子郵件地址的域名部分必須符合嚴格的規則:它必須滿足對主機名的要求,一個以點分隔的DNS標籤序列,每個標籤被限定為長度不超過63個字元,且只能由下列字元組成:  該規則也被稱為“LDH規則”(Letters, Digits, Hyphen,即字母、數字、連字元)。此外,該域也可以是一個包以方括號codice_35的IP地址的形式,例如codice_36或codice_37。但是除了垃圾郵件,這很少見。國際化域名(會被編碼,以遵守主機名的要求)允許使用非ASCII字元的域。在符合 RFC 6531 和 RFC 6532 的郵件系統中,電子郵件地址可以用UTF-8來編碼,域內部分和域名都可以。  域名和域內部分一樣,可以包含註釋;例如,codice_38和codice_39都等同於codice_21。

  根據 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伺服器提供了一種機制,以便在傳輸擴充套件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則允許。相容它的伺服器能夠處理這些地址:
電子郵件地址是傳送電子郵件時用來標示電子郵箱的一串字元,也稱為電子郵箱地址或電子信箱地址。早期的電子郵件系統曾使用非電子郵件地址,但從1980年代起,隨著網際網路郵件系統標準的開發,到今天只保留了單一的格式。本條目使用的術語“電子郵件地址”指的是RFC 5322中定義的地址規範(英語:addr-spec),而不是通常使用的地址;他們的區別是,“地址”可以包含顯示名稱和/或註釋。