電子郵件地址- 維基百科,自由的百科全書

文章推薦指數: 80 %
投票人數:10人

電子郵件地址是發送電子郵件時用來標示電子郵箱的一串字符,也稱為電子郵箱地址或電子信箱地址。

早期的電子郵件系統曾使用各種各樣的格式(英語:Non-Internet email ... 電子郵件地址 維基百科,自由的百科全書 跳至導覽 跳至搜尋 一個電子郵件地址的例子 電子郵件地址是發送電子郵件時用來標示電子郵箱的一串字符,也稱為電子郵箱地址或電子信箱地址。

早期的電子郵件系統曾使用各種各樣的格式(英語:Non-Internetemailaddress),但從1980年代起,隨著網際網路郵件系統標準的開發,到今天只保留了單一的格式。

本條目使用的術語「電子郵件地址」指的是RFC5322中定義的地址規範(addr-spec),而不是通常使用的地址;他們的區別是,「地址」可以包含顯示名稱和/或注釋。

一個電子郵件地址,比如[email protected],由域內部分、@符號和大小寫不敏感的域名組成。

雖然標準要求域內部分大小寫敏感,[1]但它又鼓勵接收主機以大小寫不敏感的方式發送消息。

[2]例如,example.com的郵件系統將John.Smith與john.smith等同對待;某些郵件系統,例如Gmail,甚至將它們視為等同於johnsmith。

[3]郵件系統往往限制其用戶對名稱的選擇,將其限定於一個技術上有效的字符集的子集內,在某些情況下甚至會對收件人地址作出限制。

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

目次 1概述 2規則 2.1域內部分 2.2域名 2.3例子 3通用域內部分語義 3.1域內部分正規化 3.2子地址 4驗證和校驗 4.1身份驗證 5國際化 5.1國際化例子 5.2國際化支持 6標準文件 7參見 8參考文獻 概述[編輯] 電子郵件在網際網路上傳輸,使用的是簡單郵件傳輸協議(SMTP),這是由網際網路標準RFC5321和RFC5322及其擴展,如RFC6531所定義的。

用戶可以使用軟體,通過郵局協議(POP)或網際網路信息訪問協議(IMAP)來訪問和管理郵箱。

這些軟體可以是運行在個人電腦、行動裝置上的電子郵件客戶端軟體,也可以是將消息呈現在屏幕上或列印輸出在紙上的Webmail系統。

電子郵件地址的通用格式為「域內部分@域」,例如[email protected]

一個地址由兩部分組成。

@符號之前的部分(域內部分)標識郵箱的名稱,它往往是接收者的用戶名,例如jsmith。

@符號之後的部分(域)是一個域名,代表郵箱的行政領域,例如一家公司的域名,example.com。

在傳遞郵件時,SMTP客戶端,例如郵件用戶代理(MUA)和消息傳輸代理(英語:Messagetransferagent)(MTA),使用域名系統(DNS)來查找收件人域的資源記錄(RR)(電子郵件地址中@右邊的部分);如果有郵件交換資源記錄(MX記錄),那麼返回的MX記錄中就會包含接收人郵件伺服器的名字,否則SMTP客戶端就會使用地址記錄(A或AAAA)。

然後MTA作為SMTP客戶端連接到這台伺服器。

電子郵件地址的域內部分對中間郵件中繼系統來說並無意義,只有到了最終郵箱主機之後才有意義。

電子郵件的發件人和中繼系統不能假定它是大小寫不敏感的,因為最終的郵箱主機既可以視之為大小寫敏感,也可以視之為大小寫不敏感。

一個郵箱可能會收到多個電子郵件地址的郵件,如果管理員這樣配置的話。

相反,一個電子郵件地址也可以是一個對應多個郵箱的發送列表的別名。

電子郵件別名(英語:Emailalias)、電子郵件列表、子地址和捕獲所有(英語:Emailfiltering)地址,即郵箱接收消息時不管域內部分,是幾種通用的模式,以實現投遞目標多樣化。

郵件交換器在遞送消息時,並不直接使用電子郵件消息頭欄位中的地址。

電子郵件消息還包著一個寫有郵件路由信息的消息信封。

信封和頭地址可以相同,偽造的電子郵件地址常常出現在垃圾郵件、釣魚郵件和許多其它的基於網際網路的詐騙中。

已經有很多倡議,想使這些偽造地址更易識別。

為了表明消息的接收者,電子郵件地址也可以有一個所關聯收件人的顯示名,而地址則放在後面的尖括號中,例如:JohnSmith

早期在網際網路之外其它網絡上的電子郵件地址(英語:Non-Internetemailaddress)形式,包括了其它一些標記,例如,X.400(英語:X.400)要求的,以及UUCP的「嘆號路徑(英語:Bangpath)」標記,這種地址是以消息中繼時需要穿過的一系列計算機的形式給出的。

這種形式被廣泛地使用了好多年,但最終被網際網路工程任務組(IETF)頒布的網際網路標準所取代。

規則[編輯] 電子郵件地址的格式是域内部分@域,其中域內部分最長為64個字符,而域名最長可達255個字符。

[4]正式的定義在RFC5322(3.2.3節和3.4.1節)和RFC5321中——RFC3696中有一個可讀性更強的形式[5]及相關勘誤表。

注意,與RFC1034和RFC1035的規則不同,它的域名沒有後面的點。

域內部分[編輯] 電子郵件地址的域內部分可以使用以下任何ASCII字符: 大小寫拉丁(英語:BasicLatin(Unicodeblock))字母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字符之外,RFC6531還允許以UTF-8編碼的U+007F以上的國際字符,但即使是支持SMTPUTF8和8BITMIME的郵件系統,在分配域內部分時也可能會限制使用的字符。

域內部分可以是用以點分隔的字符串,也可以是以引號包圍的字符串,但不能兩者都是。

但是,以引號包圍的字符串和字符並非常用的。

RFC5321還警告說:「期望接受郵件的主機,應當避免將郵箱定義為:域內部分要求(或使用)以引號包圍的字符串的形式」。

域內部分postmaster是被特殊對待的——它是大小寫不敏感的,並且應當將發往該地址的郵件發送到該域的電子郵件管理員。

技術上來講,所有其它的域內部分都是大小寫敏感的,因此[email protected][email protected]標識的是兩個不同的郵箱;然而實際上,許多組織將大寫字母與小寫字母等同對待。

事實上,RFC5321警告說:「期望接受郵件的主機,應當避免將郵箱定義為:……域內部分是大小寫敏感的」。

儘管範圍廣泛的特殊字符在技術上是有效的,但在實踐中,組織、郵件服務、郵件伺服器和郵件客戶端,往往並不能接受所有這些字符。

例如,Hotmail所允許創建的電子郵件地址只能使用字母、數字、點(.)、下劃線(_)和連字符(-)。

[7]通常的建議是,避免使用某些特殊字符,從而避免電子郵件被拒絕的風險。

[8] 域名[編輯] 電子郵件地址的域名部分必須符合嚴格的規則:它必須滿足對主機名的要求,一個以點分隔的DNS標籤序列,每個標籤被限定為長度不超過63個字符,且只能由下列字符組成:[6]:§2 大小寫拉丁(英語:BasicLatin(Unicodeblock))字母A到Z和a到z; 數字0到9,但頂級域名不能是純數字; 連字符-,但不能作為首尾字符。

該規則也被稱為「LDH規則」(Letters,Digits,Hyphen,即字母、數字、連字符)。

此外,該域也可以是一個包以方括號[]的IP位址的形式,例如jsmith@[192.168.2.1]或jsmith@[IPv6:2001:db8::1]。

但是除了垃圾郵件,這很少見。

國際化域名(會被編碼,以遵守主機名的要求)允許使用非ASCII字符的域。

在符合RFC6531和RFC6532的郵件系統中,電子郵件地址可以用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;gi[j\k][email protected](域內部分所有的特殊字符,都不允許出現在引號外) just"not"[email protected](引號中的字符串必須是點分隔的,或者是組成域內部分的唯一元素) thisis"not\[email protected](空格、引號和反斜線,只能存在於引號中,並且前面要有一個反斜線) this\still\"not\\[email protected](即使在前面加了一個反斜線,空格、引號和反斜線仍然必須包含在引號中) 1234567890123456789012345678901234567890123456789012345678901234+x@example.com域內部分超過64個字符) [email protected](@之前有兩個連續的點) [email protected](@之後有兩個連續的點) 通用域內部分語義[編輯] 根據RFC53212.3.11「郵箱及地址」,「……只有指定在地址的域中的主機,才能解讀和分配域內部分的語義。

」(「……thelocal-partMUSTbeinterpretedandassignedsemanticsonlybythehostspecifiedinthedomainoftheaddress.」)這意味著,對另一台郵件伺服器的域內部分的含義,不能作出任何假設。

這完全取決於該郵件伺服器的配置。

域內部分正規化[編輯] 對電子郵件地址「域內部分」的解釋,依賴於郵件伺服器所實現的慣例和策略。

例如,大小寫敏感性可以用來區分不同的郵箱,因此域內部分的字符只使用大寫,雖然這不是很常見。

[9]Gmail會忽略域內部分所有的點,以確定帳戶的身分。

[10]這可以防止當帳戶your.username已經存在時,創建用戶帳戶your.user.name或yourusername。

子地址[編輯] 某些郵件服務支持在域內部分包含一個標記,這樣該地址就是域內部分前綴的一個別名。

例如,地址[email protected]表示與[email protected]相同的投遞地址。

RFC5233將這種地址稱為子地址(sub-addressing),但它也可以被稱為加號地址(plusaddressing)或標記地址(taggedaddressing)。

這種形式的地址,在基本名稱和標記之間可能會使用不同的分隔符,有不少電子郵件服務都支持,包括Runbox(英語:Runbox)(加號)、Gmail(加號)、[11]RackspaceEmail(英語:RackspaceEmail)(加號)、Yahoo!MailPlus(連字號)、[12]蘋果的iCloud(加號)、Outlook.com(加號)、[13]ProtonMail(加號)、[14]FastMail(加號和子域名地址)、[15]MMDF(英語:MMDF)(等號)、Qmail和信使郵件伺服器(英語:CourierMailServer)(連字符)。

[16][17]Postfix還允許從合法字符集中任選一個字符配置作為分隔符。

[18] 這種標記的文本可用於過濾,[16]或創建一次性電子郵件地址(英語:Disposableemailaddress)。

[19] 在實踐中,某些網站的表單驗證會拒絕特殊的字符,比如在電子郵件地址中使用「+」,錯誤地將它們作為無效字符來處理。

這可能會導致電子郵件被發送給錯誤的用戶,如果「+」被網站悄悄地刪掉而且沒有任何警告或錯誤信息的話。

例如,打算發到用戶輸入的電子郵件地址[email protected]的電子郵件,可能會被錯誤地發送到[email protected]中。

另一種情況是,如果網站的某些部分,比如用戶登記頁面,允許「+」字符,但其他部分,比如從網站的郵件列表中取消訂閱的頁面,並不允許,則可能會導致用戶體驗很差。

驗證和校驗[編輯] 在網站驗證用戶身份時,常常會要求輸入電子郵件地址,以進行數據驗證(英語:Datavalidation)。

某些網站在進入時會驗證電子郵件地址,通常會使用應用程式接口,但無法保證它能提供準確的結果。

[20] 識別電子郵件地址,通常要判斷是否有兩個部分以@連接。

但是,RFC822及後續RFC技術規範中說明得更加詳細。

[21]用正則表達式可以檢查所有這些標準,除了括號內的注釋。

[22] 經過驗證的語法上正確的電子郵件地址,並不能保證存在這樣的電子郵箱。

因此許多郵件伺服器使用其它技術,並依靠相應的系統來檢查郵箱是否存在。

例如,通過域名系統來檢查域名,或使用回調校驗(英語:Callbackverification)來檢查郵箱是否存在。

但是這種方式往往無法避免目錄收割攻擊(英語:DirectoryHarvestAttack)。

確保電子郵件地址是好的,需要結合各種驗證技術。

大型網站、批量郵件和垃圾郵件的發送者要求快速的算法,來預測電子郵件地址的有效性。

這種方法嚴重依賴於啟發式搜索和概率模型。

[23] 許多網站在評估電子郵件地址有效性時,與標準規範不同,會拒絕地址中包含某些有效字符,例如「+」和「/」,或限制其長度。

RFC3696提供了具體的建議,來驗證網際網路標識符,包括電子郵件地址。

許多瀏覽器已經實現了HTML5的表單,使得電子郵件地址的驗證可以由瀏覽器來處理。

[24] 電子郵件地址國際化所允許的字符集,遠遠超出了當前許多驗證算法所允許的字符集,例如所有U+0080以上的Unicode字符,以UTF-8編碼。

身份驗證[編輯] 電子郵件地址是激活帳戶的首要手段(在網站上進行用戶識別和驗證),但也可以用其它方法,如手機號碼驗證、郵政郵件驗證、傳真驗證。

用電子郵件地址驗證時,網站通過電子郵件將一個特殊的臨時超鏈發送到用戶提供的電子郵件地址。

用戶在收到該郵件後,打開連結,帳戶立即就被激活了。

電子郵件地址也可以被網站用作轉發消息的手段,例如,轉發用戶消息、用戶操作到電子郵件收件箱。

國際化[編輯] IETF成立了一個技術和標準工作組,致力於電子郵件地址的國際化問題,稱為「電子郵件地址國際化」(EmailAddressInternationalization,簡稱EAI)或「國際化郵件地址」(InternationalizedMailAddress,簡稱IMA)。

[25]該工作組制定了RFC6530、RFC6531、RFC6532和RFC6533,並繼續為其它EAI相關的RFC而工作。

IETF的EAI工作組發布了RFC6530「國際化電子郵件概述與框架」,它使得在電子郵件地址的域內部分和域名中都可以使用非ASCII字符。

RFC6530為電子郵件提供的方案是基於UTF-8編碼,該編碼支持Unicode的所有字符。

RFC6531為SMTP伺服器提供了一種機制,以便在傳輸SMTPUTF8(英語:ExtendedSMTP#SMTPUTF8)內容時進行溝通。

EAI的基本概念涉及了以UTF-8交換郵件。

原始方案中還包含了對遺留系統向下兼容的機制,但現在它已經被丟棄。

[26]本地伺服器負責地址的域內部分,而域名則會受到國際化域名規則的限制,儘管仍然以UTF-8發送。

郵件伺服器還需要負責在IMA形式和任意ASCII別名之間建立所有的映射機制。

EAI使用戶可以有一個以母語表示的本地化地址,同時還有一個ASCII形式,以便與遺留系統通訊使用,或作為獨立腳本使用。

識別國際化域名和郵件地址的應用程式,必須具有轉換這些表達方式的設備。

有些國家或地區預計會對這樣的地址需求較大,比如中國、日本、俄羅斯,以及其它存在大量用戶使用非基於拉丁文的書寫系統的市場。

例如,2011年,印度政府在頂級域.in之外,批准了「.bharat」(表示BhāratGaṇarājya,即印度共和國)頂級域名,並以七種不同文字書寫,[27][28][29]以方便古吉拉特語、馬拉地語、孟加拉語、泰米爾語、泰盧固語、旁遮普語和烏爾都語用戶使用。

印度公司XgenPlus.com聲稱其是世界上第一個EAI郵箱提供者,[30]而拉賈斯坦邦政府(英語:GovernmentofRajasthan)現在為該邦每位公民提供免費的域名為राजस्थान.भारत的電子郵件帳戶。

[31]一家領先的媒體公司拉賈斯坦雜誌(RajasthanPatrika)上線了他們的IDN域名पत्रिका.भारत及可用來聯繫的電子郵件。

國際化例子[編輯] 基於RFC5322的伺服器不能處理以下例子中的地址,而RFC6530則允許。

兼容它的伺服器能夠處理這些地址: 帶附加符號的拉丁字母:Pelé@example.com 希臘字母:δοκιμή@παράδειγμα.δοκιμή 繁體漢字:我買@屋企.香港 日文字符:二ノ宮@黒川.日本 西里爾字母:чебурашка@ящик-с-апельсинами.рф 天城體文字:संपर्क@डाटामेल.भारत 國際化支持[編輯] Postfix代理(英語:Messagetransferagent)從2015年2月8日的穩定版3.0.0開始支持國際化郵件。

[32] Google支持向國際化域名發送電子郵件和從國際化域名接收郵件,但是不允許註冊含有非ASCII字符的電子郵件地址。

[33] 微軟在Outlook2016中加入了類似的功能。

[34] DataMail在印度上線了國際化電子郵件支持,包括8種印度語言,使用XgenPlus電子郵件平台。

[35] 標準文件[編輯] RFC821——簡單郵件傳輸協議(由RFC2821取代) RFC822——ARPA網際網路文本消息格式標準(由RFC2822取代)(勘誤表) RFC1035——域名及其實現與規範(勘誤表) RFC1123——對網際網路主機、應用和支持的要求(由RFC2821、RFC5321更新)(勘誤表) RFC2142——通用服務、角色和功能的郵箱名稱(勘誤表) RFC2821——簡單郵件傳輸協議(取代RFC821,更新RFC1123,由RFC5321取代)(勘誤表) RFC2822——網際網路消息格式(取代RFC822,由RFC5322取代)(勘誤表) RFC3696——用於檢查和名稱轉換的應用程式技術(勘誤表) RFC4291——IPv6的尋址架構(由RFC5952更新)(勘誤表) RFC5321——簡單郵件傳輸協議(取代RFC2821,更新RFC1123)(勘誤表) RFC5322——網際網路消息格式(取代RFC2822,更新RFC6854)(勘誤表) RFC5952——關於IPv6地址的文本表示的建議(更新RFC4291)(勘誤表) RFC6530——國際化電子郵件概述與框架(取代RFC4952、5504、5825) RFC6854——更新網際網路消息格式,以允許在「發件人」頭欄位中使用分組語法(更新RFC5322) 參見[編輯] 反垃圾郵件技術 電子郵件客戶端 電子郵箱 電子郵件認證(英語:Emailauthentication) 國際電子郵件(英語:Internationalemail) 參考文獻[編輯] ^J.Klensin.GeneralSyntaxPrinciplesandTransactionModel[通用语法规则与事务模型].SimpleMailTransferProtocol.2008-10:p. 15. sec. 2.4.RFC5321(英文)."Thelocal-partofamailboxMUSTBEtreatedascasesensitive.[郵箱的域內部分必須按大小寫敏感處理。

]"  ^J.Klensin.GeneralSyntaxPrinciplesandTransactionModel[通用语法规则与事务模型].SimpleMailTransferProtocol.2008-10:p. 15. sec. 2.4.RFC5321(英文)."However,exploitingthecasesensitivityofmailboxlocal-partsimpedesinteroperabilityandisdiscouraged.[然而,郵箱域內部分的大小寫敏感性阻礙了互通性,因此不建議這樣做。

]"  ^收到他人的邮件.Google.如果發件人在您的電子郵件地址中添加了點,您仍會收到該電子郵件。

  ^RFC5321 ^作者為J.Klensin,與RFC5321的作者相同 ^6.06.1RFC3696:§3 ^创建帐户.[2019-01-17].  ^Charactersinthelocalpartofanemailaddress[電子郵件地址域內部分中的字符].[2016-03-30](英語).  ^HeinzTschabitscher.AreEmailAddressesCaseSensitive?[電子郵件地址是大小寫敏感的嗎?](英語).  ^收到他人的邮件.Google.[2019-02-23].  ^通过其他地址或别名发送电子邮件.Google.[2019-02-23].  ^DisposableaddressesinYahooMail-YahooHelp-SLN3523[YahooMail中的一次性地址-Yahoo幫助-SLN3523].[2019-02-23](英語).  ^Outlook.comsupportssimpler"+"emailaliasestoo[Outlook.com也支持簡單的「+」電子郵件別名].WithinWindows.(原始內容存檔於2014-02-20)(英語).  ^AddressesandAliases[地址與別名].ProtonMail(英語).  ^Plusaddressingandsubdomainaddressing[加號地址和子域名地址].FastMail(英語).  ^16.016.1Dot-Qmail,Controlthedeliveryofmailmessages[點-Qmail,控制郵件消息的遞送].[2012-01-27].(原始內容存檔於2012-01-26)(英語).  ^Sill,Dave.4.1.5.extensionaddresses[4.1.5.擴展地址].Lifewithqmail.[2012-01-27].(原始內容存檔於2012-02-29)(英語).  ^PostfixConfigurationParameters[Postfix配置參數].Postfix(英語).  ^GinaTrapani.InstantdisposableGmailaddresses[方便的一次性Gmail地址].2005(英語).  ^Paul,Andrew.WhenaValidandDeliverableEmailisNeitherValidnorDeliverable[當有效且可投遞的電子郵件既無效也無法投遞時].EmailAnswers.[2013-04-26].(原始內容存檔於2013-05-01)(英語).  ^IKnewHowToValidateAnEmailAddressUntilIReadTheRFC[直到我讀了RFC,我才知道如何驗證電子郵件地址](英語).  ^Mail::RFC822::Address[郵件::RFC822::地址](英語).  ^JanHornych.Verification&ValidationTechniquesforEmailAddressQualityAssurance[保證電子郵件地址質量的校驗和驗證技術](PDF).牛津大學.2011(英語).  ^4.10Forms—HTML5[4.10表單—HTML5].W3C(英語).  ^EaiStatusPages[EAI狀態頁].電子郵件地址國際化(活躍的工作組).IETF.2013-03-18[2008-07-26](英語).  ^EmailAddressInternationalization(eai)[電子郵件地址國際化(EAI)].IETF.[2010-11-30](英語).  ^2011-01-25-ApprovalofDelegationoftheseventop-leveldomainsrepresentingIndiainvariouslanguages-myICANN.org[2011-01-25-代表印度各種語言的七個頂級域獲批-myICANN.org](英語).  ^Registry.In[國際化域名(IDN)|Registry.In].[2016-10-17].(原始內容存檔於2016-05-13)(英語).  ^Now,getyouremailaddressinHindi-TheEconomicTimes[現在,取得您的印地語電子郵件地址-經濟時代].經濟時代(英語:TheEconomicTimes).[2016-10-17].(原始內容存檔於2016-08-28)(英語).  ^UniversalAcceptanceinIndia[在印度普遍接受](英語).  ^देशमेंपहला,प्रदेशकेहरनागरिककेलिएमुफ्तई-वॉल्टऔरई-मेलकीसुविधाशुरू-वसुन्धराराजे[CM上線了該邦每位公民都可免費使用的電子郵件和電子銀行].वसुन्धराराजे.2017-08-18[2017-08-20](印地語).  ^'Postfixstablerelease3.0.0'–MARC['Postfix穩定版3.0.0'–MARC].marc.info(英語).  ^Afirststeptowardmoreglobalemail[朝向更加全球化的電子郵件邁進的第一步].Google.[2014-08-06](英語).  ^What'snewinOutlook2016forWindows[Windows版Outlook2016有哪些新功能].support.office.com(英語).  ^DataMaillaunchesfreelinguisticemailserviceineightIndianlanguages[DataMail上線了免費的覆蓋八種印度語言的電子郵件服務].[2017-11-25](英語).  維基教科書中有關驗證電子郵件地址的文本 維基教科書中有關最佳實踐的文本 維基共享資源上有關電子郵件地址的多媒體資源 取自「https://zh.wikipedia.org/w/index.php?title=電子郵件地址&oldid=67979430」 分類:電子郵件隱藏分類:CS1英語來源(en)CS1印地語來源(hi)使用RFC魔術連結的頁面含有英語的條目含有日語的條目 導覽選單 個人工具 沒有登入討論貢獻建立帳號登入 命名空間 條目討論 臺灣正體 已展開 已摺疊 不转换简体繁體大陆简体香港繁體澳門繁體大马简体新加坡简体臺灣正體 查看 閱讀編輯檢視歷史 更多 已展開 已摺疊 搜尋 導航 首頁分類索引特色內容新聞動態近期變更隨機條目資助維基百科 說明 說明維基社群方針與指引互助客棧知識問答字詞轉換IRC即時聊天聯絡我們關於維基百科 工具 連結至此的頁面相關變更上傳檔案特殊頁面靜態連結頁面資訊引用此頁面維基數據項目 列印/匯出 下載為PDF可列印版 其他專案 維基共享資源 其他語言 العربيةČeštinaDanskDeutschEnglishEsperantoفارسیSuomiFrançaisHrvatskiBahasaIndonesiaÍslenska日本語한국어LatviešuОлыкмарийമലയാളംPolskiРусскийSlovenčinaУкраїнськаاردوWolof 編輯連結



請為這篇文章評分?