smtp服務(wù)擴(kuò)展的認(rèn)證機(jī)制外文翻譯@中英文翻譯@外文文獻(xiàn)翻譯

1、<p><b>　　譯文</b></p><p>　　SMTP服務(wù)擴(kuò)展的認(rèn)證機(jī)制</p><p>　　這個(gè)文檔詳細(xì)說(shuō)明了因特網(wǎng)團(tuán)體的一個(gè)標(biāo)準(zhǔn)的協(xié)議的發(fā)展，以及對(duì)其改進(jìn)和建議提出了要求。說(shuō)到這，為了標(biāo)準(zhǔn)化這個(gè)協(xié)議的狀態(tài)和地位，就必須提及目前最新的“Internet 官方協(xié)議的標(biāo)準(zhǔn)”(STD1)。發(fā)送這個(gè)文檔是不受限制的。</p><p>

2、;<b>　　版權(quán)須知</b></p><p>　　版權(quán)所有－1999年 Internet 團(tuán)體。所有權(quán)利將得到保留。</p><p><b>　　1 簡(jiǎn)介</b></p><p>　　這個(gè)文檔定義了SMTP服務(wù)的擴(kuò)展（ESMTP）并且說(shuō)明了一個(gè)SMTP客戶(hù)端可以為服務(wù)器指定一種用來(lái)執(zhí)行與認(rèn)證協(xié)議的交換，并且隨意地穿越并

3、發(fā)的協(xié)議之間交互的安全層的認(rèn)證機(jī)制。這個(gè)擴(kuò)展是“簡(jiǎn)單認(rèn)證和安全層”[SASL]的一個(gè)側(cè)面。</p><p>　　2 這個(gè)文檔用到的協(xié)定</p><p>　　在以下的這些例子中，C和S分別表示客戶(hù)端和服務(wù)器。</p><p>　　諸如MUST", "MUST NOT", "SHOULD", "SHOULD

4、NOT", and "MAY"這些關(guān)鍵性的單詞被可以看作和“用在RFC文檔中用來(lái)標(biāo)示必須的級(jí)別的關(guān)鍵字” [KEYWORDS]相同的解釋。</p><p>　　3 認(rèn)證服務(wù)的擴(kuò)展</p><p>　　SMTP服務(wù)擴(kuò)展的名稱(chēng)是 "Authentication"</p><p>　　聯(lián)合這個(gè)擴(kuò)展的EHLO關(guān)鍵字的值是“

5、AUTH“</p><p>　　(3)AUTH EHLO關(guān)鍵字 是一個(gè)有空格間隔的被SASL機(jī)制支持的名字列表的參數(shù)</p><p>　　(4)一個(gè)新的SMTP動(dòng)詞“AUTH“定義完成。</p><p>　　(5)用在關(guān)鍵字“AUTH“的一個(gè)可選的參數(shù)被附加到MAIL FROM命令里，用來(lái)指定MAIL FROM命令一行的最大長(zhǎng)度不能超過(guò)500個(gè)字符。</p&g

6、t;<p>　　(6) 此擴(kuò)展和委托協(xié)議兼容。</p><p><b>　　4 AUTH命令</b></p><p>　　AUTH機(jī)制[初始化響應(yīng)]</p><p><b>　　觀點(diǎn)：</b></p><p>　　用來(lái)標(biāo)識(shí)SASL認(rèn)證機(jī)制的一個(gè)字符串</p><p

7、>　　可選的Base64編碼的一個(gè)響應(yīng)</p><p><b>　　約束：</b></p><p>　　再成功發(fā)出了一個(gè)AUTH命令之后，在同一時(shí)間段里不能再執(zhí)行其他的AUTH命令。在成功執(zhí)行了一個(gè)AUTH命令之后，服務(wù)器必須拒絕后來(lái)的AUTH命令并且返回一個(gè)503響應(yīng)碼。</p><p>　　在處理一個(gè)郵件事務(wù)期間，服務(wù)器不會(huì)再接受AU

8、TH命令。</p><p><b>　　討論：</b></p><p>　　AUTH命令顯示了一種和郵件服務(wù)器間的安全認(rèn)證機(jī)制 。如果郵件服務(wù)器支持這種認(rèn)證機(jī)制，它就會(huì)執(zhí)行一個(gè)認(rèn)證協(xié)議交互來(lái)認(rèn)證并識(shí)別郵件用戶(hù)。作為可選的情況，他也會(huì)忽略這以后后協(xié)議交互的一個(gè)安全層。如果服務(wù)器并不支持所需要的認(rèn)證協(xié)議，就會(huì)用504的回答來(lái)拒絕這個(gè)AUTH命令。</p>&

9、lt;p>　　這種認(rèn)證機(jī)制的交互由一些列的服務(wù)器的響應(yīng)和對(duì)認(rèn)證機(jī)制來(lái)說(shuō)的一些特殊的回答來(lái)組成。服務(wù)器的正確響應(yīng)，不同于其他的響應(yīng)的是針對(duì)文本部分采用Base64編碼以334做為回應(yīng)的?？蛻?hù)端的回應(yīng)是一個(gè)包含Base64編碼的字符串的隊(duì)列。如果客戶(hù)端想取消與服務(wù)器的認(rèn)證交互，就執(zhí)行一個(gè)單個(gè)的“*”。如果服務(wù)器接到這樣一個(gè)回應(yīng)，就通過(guò)發(fā)送一個(gè)501的響應(yīng)來(lái)拒絕執(zhí)行AUTH命令。</p><p>　　對(duì)AUTH命

10、令來(lái)說(shuō)，可選的初始化響應(yīng)建議是用來(lái)在使用認(rèn)證機(jī)制時(shí)保持一個(gè)往</p><p>　　返的回程,認(rèn)證機(jī)制的定義中此建議不發(fā)送任何數(shù)據(jù)。當(dāng)初始化響應(yīng)部分用在這種機(jī)制時(shí)，</p><p>　　開(kāi)始的空的發(fā)起命令不被送到客戶(hù)端，并且服務(wù)器端使用的數(shù)據(jù)也好象是發(fā)送來(lái) </p><p>　　響應(yīng)一個(gè)空的命令。它發(fā)送一個(gè)零長(zhǎng)度的初始化回答作為一個(gè)"=&qu

11、ot;符號(hào)。如果客戶(hù)端 </p><p>　　在認(rèn)證機(jī)制的AUTH命令響應(yīng)中使用初始化建議，客戶(hù)端就在初始化命令中發(fā)送響應(yīng)的 </p><p>　　數(shù)據(jù)，服務(wù)器端用535回答來(lái)拒絕AUTH命令。</p><p>　　如果服務(wù)器不能對(duì)發(fā)送來(lái)的命令采用Base64解碼的話(huà)，將拒絕執(zhí)行Auth命令，并返回501響應(yīng)。如果服務(wù)器拒絕認(rèn)證的數(shù)據(jù)

12、，服務(wù)器應(yīng)該拒絕執(zhí)行并返回一個(gè)535響應(yīng)碼除非有更詳細(xì)的錯(cuò)誤代碼，例如在Section 6列出來(lái)的那個(gè)。如果客戶(hù)端和服務(wù)器進(jìn)行了正確的交互的操作的話(huà)，SMTP服務(wù)器將發(fā)出一個(gè)235響應(yīng)碼。</p><p>　　詳細(xì)說(shuō)明這個(gè)SASL側(cè)面的服務(wù)器的名稱(chēng)是”SMTP“。</p><p>　　如果SASL認(rèn)證交互穿越了一個(gè)安全層，將會(huì)通過(guò)一個(gè)有用來(lái)中止認(rèn)證交互的CRLF來(lái)產(chǎn)生效果，而服務(wù)器也通過(guò)一

13、個(gè)CRLF做出正確的響應(yīng)。在服務(wù)器的安全層生效之前，SMTP協(xié)議被重置到初始狀態(tài)（SMTP中的狀態(tài)是服務(wù)器發(fā)出了一個(gè)220服務(wù)的問(wèn)候之后）。服務(wù)器MUST命令將拋棄所有的不是通過(guò)客戶(hù)端而得到的認(rèn)知，比如不是通過(guò)SASL本身而獲得認(rèn)知的EHLO命令的論點(diǎn)?？蛻?hù)端的MUST命令將拋棄所有的從服務(wù)器獲得的認(rèn)知，例如不是通過(guò)SASL本身而獲得的SMTP服務(wù)擴(kuò)展的隊(duì)列?？蛻?hù)端的SHOULD在SASL商議成功之后，發(fā)出一個(gè)EHLO命令做為第一個(gè)命令

14、，這些將使得安全層得到授權(quán)。</p><p>　　服務(wù)器不一定要求支持任何的認(rèn)證機(jī)制，而認(rèn)證機(jī)制也不一定要支持所有的安全層。如果一個(gè)AUTH命令失敗了，客戶(hù)端將試圖執(zhí)行另一個(gè)認(rèn)證機(jī)制的AUTH命令。</p><p>　　一個(gè)Base64編碼的字符串通常來(lái)說(shuō)是沒(méi)有長(zhǎng)度限制的。只要由認(rèn)證機(jī)制產(chǎn)生的受客戶(hù)端和服務(wù)器支持的命令和響應(yīng)，客戶(hù)端和服務(wù)器端必須支持，而不依賴(lài)于服務(wù)器或者客戶(hù)端的、可能存在

15、于協(xié)議實(shí)現(xiàn)的某些方面的行長(zhǎng)度的限制。</p><p><b>　　例如：</b></p><p><b>　　Examples:</b></p><p>　　S: 220 smtp.example.com ESMTP server ready</p><p>　　C: EHLO jgm.exampl

16、e.com</p><p>　　S: 250-smtp.example.com</p><p>　　S: 250 AUTH CRAM-MD5 DIGEST-MD5</p><p>　　C: AUTH FOOBAR</p><p>　　S: 504 Unrecognized authentication type.</p><

17、;p>　　C: AUTH CRAM-MD5</p><p><b>　　S: 334</b></p><p>　　PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=</p><p>　　C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjN

18、iYmFlNzg2ZQ==</p><p>　　S: 235 Authentication successful.</p><p>　　5. AUTH命令的參數(shù)附加到的MAIL FROM命令</p><p>　　AUTH=addr-spec</p><p><b>　　參數(shù)：</b></p><p

19、>　　一個(gè)包含標(biāo)志的被提交給傳送系統(tǒng)的addr-spec，或者是兩個(gè)字符組成的序列"<>" ,</p><p>　　表明這個(gè)標(biāo)志是未知的或被驗(yàn)明為不完成的。</p><p><b>　　討論：</b></p><p>　　AUTH中一個(gè)可選的參數(shù)的MAIL FROM 命令允許一個(gè)協(xié)同工作的代理與一單獨(dú)的消息

20、就行通信在一個(gè)被信任的環(huán)境里。</p><p>　　如果服務(wù)器認(rèn)為最初提交消息的Addr－dec的客戶(hù)端是可信任的話(huà)，將會(huì)發(fā)出一個(gè)聲明，接著服務(wù)器應(yīng)當(dāng)提供一個(gè)相同的addr－dec給任何其他支持AUTH擴(kuò)展的用來(lái)中轉(zhuǎn)消息的服務(wù)器。</p><p>　　如果MAIL FROM命令中那個(gè)可選的AUTH命令的參數(shù)沒(méi)有得到提供的話(huà)，而客戶(hù)端已經(jīng)得到認(rèn)證，那么服務(wù)器認(rèn)為消息是由客戶(hù)端提交的原始的信息

21、，那么在中轉(zhuǎn)給其他的中繼服務(wù)器的時(shí)候，當(dāng)前服務(wù)器就會(huì)把a(bǔ)ddr－dec做為Auth命令的可選的參數(shù)提供給其它的服務(wù)器。</p><p>　　如果服務(wù)器不是充分的相信客戶(hù)端的身份或者客戶(hù)端并沒(méi)有得到認(rèn)證的話(huà)，那么服務(wù)器必須自己提供AUTH命令的那個(gè)參數(shù)一個(gè)值。并且將這個(gè)值寫(xiě)入到日志文件中。</p><p>　　如果AUTH命令的可選的參數(shù)已經(jīng)提供了的話(huà)，不管是明確的提出還是由于前面段落的需要

22、，服務(wù)器應(yīng)當(dāng)提供這個(gè)參數(shù)給任何其他支持AUTH擴(kuò)展的用來(lái)中轉(zhuǎn)消息的服務(wù)器。</p><p>　　服務(wù)器將把郵件列表的擴(kuò)充視為一個(gè)新的任務(wù)，AUTH命令加入到郵件地址列表中，或者在中轉(zhuǎn)這些消息到列表簽署者的時(shí)候管理郵件列表。</p><p>　　為了一致，在一個(gè)執(zhí)行很難被編碼的時(shí)候，服務(wù)器將認(rèn)為所有的這些客戶(hù)端都是不可信任的。在這種情況下，服務(wù)器能做的僅僅就是解析有效的AUTH命令的參數(shù)，并

23、把它提供給任所有使用AUTH擴(kuò)展的認(rèn)證機(jī)制的服務(wù)器，并遺棄無(wú)效的參數(shù)。</p><p><b>　　例如：</b></p><p>　　C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com</p><p><b>　　S: 250 OK</b><

24、;/p><p><b>　　6 錯(cuò)誤代碼</b></p><p>　　以下的錯(cuò)誤代碼常常用來(lái)描述和標(biāo)識(shí)各種情況。</p><p>　　432 需要進(jìn)行密碼的轉(zhuǎn)換</p><p>　　這個(gè)響應(yīng)碼表示，對(duì)于服務(wù)器的認(rèn)證機(jī)制來(lái)講，用戶(hù)必須進(jìn)行一個(gè)轉(zhuǎn)換。比較由代表性的就是一旦你使用了PLAIN認(rèn)證機(jī)制的話(huà)，就必須進(jìn)行轉(zhuǎn)換。&l

25、t;/p><p>　　534 認(rèn)證機(jī)過(guò)于簡(jiǎn)單</p><p>　　這個(gè)響應(yīng)碼表示的是選擇的認(rèn)證機(jī)制相對(duì)于服務(wù)器所允許的認(rèn)證機(jī)制來(lái)說(shuō)顯得太弱了。</p><p>　　538 請(qǐng)求的認(rèn)證機(jī)制需要加密</p><p>　　這個(gè)響應(yīng)碼表示的是所選的認(rèn)證機(jī)制只有在SMTP連接是需要加密的情況下才用的著</p><p>　　454

26、 暫時(shí)的認(rèn)證失敗</p><p>　　這個(gè)響應(yīng)碼表示的是認(rèn)證失敗的原因是由于服務(wù)器暫時(shí)出現(xiàn)問(wèn)題</p><p>　　530 認(rèn)證是必須的</p><p>　　除了AUTH，EHLO，HELO，NOOP，RESET或者QUIT這幾個(gè)命令之外的任何一個(gè)命令，都將返回這個(gè)響應(yīng)碼。這表示服務(wù)器需要為了執(zhí)行被請(qǐng)求的操作，需要一個(gè)認(rèn)證。</p><p&g

27、t;<b>　　7 正規(guī)的語(yǔ)法</b></p><p>　　以下的用在擴(kuò)展的BNF符號(hào)和用在ABNF中的語(yǔ)法的規(guī)格是一樣的。</p><p>　　除了那些被標(biāo)注的以外，所有的按字母順序排列的特征都是適合于固定場(chǎng)合的。排在上面的或者下面的被用來(lái)定義為有象征意義的字符串的用處僅僅是為了編輯時(shí)的便利以及清晰。執(zhí)行這些必須在以固定的格式在一定的場(chǎng)合來(lái)接受這些字符串。<

28、/p><p>　　UPALPHA = %x41-5A ;; Uppercase: A-Z</p><p>　　LOALPHA = %x61-7A ;; Lowercase: a-z</p><p>　　ALPHA = UPALPHA / LOALPHA ;; case insensitive</p><p>　　DIGIT = %x30-39 ;

29、; Digits 0-9</p><p>　　HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)</p><p>　　hexchar = "+" HEXDIGIT HEXDIGIT</p><p>　　xchar = %x21-2A / %x2C-3C / %x3E-7E<

30、/p><p>　　;; US-ASCII except for "+", "=", SPACE and CTL</p><p>　　xtext = *(xchar / hexchar)</p><p>　　AUTH_CHAR = ALPHA / DIGIT / "-" / "_"</p

31、><p>　　auth_type = 1*20AUTH_CHAR</p><p>　　auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]</p><p>　　*(CRLF [base64]) CRLF</p><p>　　auth_par

32、am = "AUTH=" xtext</p><p>　　;; The decoded form of the xtext MUST be either</p><p>　　;; an addr-spec or the two characters "<>"</p><p>　　base64 = base64_te

33、rminal /</p><p>　　( 1*(4base64_CHAR) [base64_terminal] )</p><p>　　base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"</p><p>　　;; Case-sensitive</p><p

34、>　　base64_terminal = (2base64_char "==") / (3base64_char "=")</p><p>　　continue_req = "334" SPACE [base64] CRLF</p><p>　　CR = %x0C ;; ASCII CR, carriage return&l

35、t;/p><p>　　CRLF = CR LF</p><p>　　CTL = %x00-1F / %x7F ;; any ASCII control character and DEL</p><p>　　LF = %x0A ;; ASCII LF, line feed</p><p>　　SPACE = %x20 ;; ASCII SP, s

36、pace</p><p><b>　　9 安全問(wèn)題考慮</b></p><p>　　如果客戶(hù)端使用這個(gè)擴(kuò)展得到不加密的渠道但是通過(guò)一個(gè)不安全的網(wǎng)絡(luò)連接到協(xié)同工作的服務(wù)器的話(huà)，客戶(hù)端將被阻斷而永遠(yuǎn)不能發(fā)送郵件到服務(wù)器，當(dāng)服務(wù)器不能夠互助地進(jìn)行驗(yàn)證和加密的時(shí)候。否則，攻擊者將會(huì)通過(guò)截?cái)郤MTP的連接而偷取客戶(hù)端的信件，或者假裝服務(wù)器不支持認(rèn)證，從而導(dǎo)致所有的AUTH命令

37、失敗。</p><p>　　在SASL商議開(kāi)始之前，任何協(xié)議之間的交互都可以暢通無(wú)阻的進(jìn)行，但也有可能被活動(dòng)著的攻擊者修改。因此客戶(hù)端和服務(wù)器都必須拋棄在SASL之前獲得的所有消息。</p><p>　　認(rèn)證機(jī)制并不保護(hù)TCP端口，攻擊者就會(huì)通過(guò)修改中轉(zhuǎn)的連接而試圖連接（SUBMIT）。AUTH命令的參數(shù)就可以阻止這種攻擊。</p><p>　　一個(gè)消息子服務(wù)客戶(hù)端

38、可能會(huì)要求用戶(hù)通過(guò)驗(yàn)證，在任何它得到一個(gè)合適的SASL的時(shí)候。</p><p>　　因此，對(duì)于一個(gè)聲明SASL機(jī)制的SUBMIT來(lái)說(shuō)并不是合算的，在使用一個(gè)同意匿名子任務(wù)的客戶(hù)端而沒(méi)有任何利益的機(jī)制的時(shí)候。</p><p>　　這個(gè)擴(kuò)展并不是有意的取代或者被用來(lái)取代端到端的消息簽名在加密系統(tǒng)S/MIME或者PGP中。此擴(kuò)展和端到端的系統(tǒng)有一些細(xì)微的差別，主要是以下的部分。</p>

39、;<p>　?。?）它通常只在一個(gè)被信任的范圍里有效</p><p>　?。?）它保護(hù)整個(gè)消息的封裝替，而不僅僅是正文</p><p>　?。?）它鑒證消息的子任務(wù)而不是消息的內(nèi)容</p><p>　　（4）在發(fā)信者協(xié)同驗(yàn)證下一個(gè)中轉(zhuǎn)點(diǎn)并且穿越一個(gè)合理的安全層的情況下，它可以給發(fā)信者一個(gè)保證，那就是可以把消息安全地傳遞到下一個(gè)地點(diǎn)。</p>

40、<p>　　另外需要說(shuō)明的是，安全問(wèn)題的考慮在SASL說(shuō)明里面也有提到。</p><p><b>　　外文文獻(xiàn)原文</b></p><p>　　SMTP Service Extension for Authentication</p><p>　　This document specifies an Internet standa

41、rds track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standar

42、dization state and status of this protocol. Distribution of this memo is unlimited.</p><p>　　Copyright Notice</p><p>　　Copyright (C) The Internet Society (1999). All Rights Reserved.</p>

43、<p>　　1. Introduction</p><p>　　This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server,perform an authentication protocol ex

44、change, and optionally negotiatea security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Security Layer [SASL].</p><p>　　2. Conventions Used in this

45、 Document</p><p>　　In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "SHOULD", "SH

46、OULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].</p><p>　　3. The Authentication servic

47、e extension</p><p>　　(1) the name of the SMTP service extension is "Authentication"</p><p>　　(2) the EHLO keyword value associated with this extension is "AUTH"</p>&l

48、t;p>　　(3) The AUTH EHLO keyword contains as a parameter a space separated list of the names of supported SASL mechanisms.</p><p>　　(4) a new SMTP verb "AUTH" is defined</p><p>　　(5)

49、 an optional parameter using the keyword "AUTH" is added to the MAIL FROM command, and extends the maximum line length of the MAIL FROM command by 500 characters.</p><p>　　(6) this extension is app

50、ropriate for the submission protocol [SUBMIT].</p><p>　　4. The AUTH command AUTH mechanism [initial-response]</p><p>　　Arguments:</p><p>　　a string identifying a SASL authentication

51、 mechanism. an optional base64-encoded response</p><p>　　Restrictions:</p><p>　　After an AUTH command has successfully completed, no more AUTH commands may be issued in the same session. After a

52、 successful AUTH command completes, a server MUST reject any further AUTH commands with a 503 reply. The AUTH command is not permitted during a mail transaction.</p><p>　　Discussion:</p><p>　　Th

53、e AUTH command indicates an authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the user. Op

54、tionally, it also negotiates a security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server rejects the AUTH command with a 504 reply.</p><p>　　

55、The authentication protocol exchange consists of a series of server challenges and client answers that are specific to the authentication mechanism. A server challenge, otherwise known as a ready response, is a 334 reply

56、 with the text part containing a BASE64 encoded string. The client answer consists of a line containing a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it issues a line with a single &

57、quot;*". If the server receives such an answer, it MUST reject th</p><p>　　The optional initial-response argument to the AUTH command is used to save a round trip when using authentication mechanisms th

58、at are defined to send no data in the initial challenge.</p><p>　　When the initial-response argument is used with such a mechanism, the initial empty challenge is not sent to the client and the server uses t

59、he data in the initial-response argument as if it were sent in response to the empty challenge. Unlike a zero-length client answer to a 334 reply, a zero- length initial response is sent as a single equals sign ("=&

60、quot;). If the client uses an initial-response argument to the AUTH command with a mechanism that sends data in the initial challenge, the server rej</p><p>　　If the server cannot BASE64 decode the argument,

61、 it rejects the AUTH command with a 501 reply. If the server rejects the authentication data, it SHOULD reject the AUTH command with a 535 reply unless a more specific error code, such as one listed in section 6, is appr

62、opriate. Should the client successfully complete the authentication exchange, the SMTP server issues a 235 reply.</p><p>　　The service name specified by this protocol's profile of SASL is "smtp"

63、;.</p><p>　　If a security layer is negotiated through the SASL authentication exchange, it takes effect immediately following the CRLF that concludes the authentication exchange for the client, and the CRLF

64、of the success reply for the server. Upon a security layer's taking effect, the SMTP protocol is reset to the initial state (the state in SMTP after a server issues a 220 service ready greeting). The server MUST disc

65、ard any knowledge obtained from the client, such as the argument to the EHLO command, whi</p><p>　　The server is not required to support any particular authentication mechanism, nor are authentication mechan

66、isms required to support any security layers. If an AUTH command fails, the client may try another authentication mechanism by issuing another AUTH command.</p><p>　　If an AUTH command fails, the server MUST

67、 behave the same as if the client had not issued the AUTH command.</p><p>　　The BASE64 string may in general be arbitrarily long. Clients and servers MUST be able to support challenges and responses that are

68、 as long as are generated by the authentication mechanisms they support, independent of any line length limitations the client or server may have in other parts of its protocol implementation.</p><p><b&g

69、t;　　Examples:</b></p><p>　　S: 220 smtp.example.com ESMTP server ready</p><p>　　C: EHLO jgm.example.com</p><p>　　S: 250-smtp.example.com</p><p>　　S: 250 AUTH CRAM-

70、MD5 DIGEST-MD5</p><p>　　C: AUTH FOOBAR</p><p>　　S: 504 Unrecognized authentication type.</p><p>　　C: AUTH CRAM-MD5</p><p><b>　　S: 334</b></p><p&g

71、t;　　PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=</p><p>　　C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==</p><p>　　S: 235 Authentication successful.</p><p>　

72、　5. The AUTH parameter to the MAIL FROM command</p><p>　　AUTH=addr-spec</p><p>　　Arguments:</p><p>　　An addr-spec containing the identity which submitted the message to the delivery

73、 system, or the two character sequence "<>" indicating such an identity is unknown or insufficiently authenticated. To comply with the restrictions imposed on ESMTP parameters, the addr-spec is encoded in

74、side an xtext. The syntax of an xtext is described in section 5 of [ESMTP-DSN].</p><p>　　Discussion:</p><p>　　The optional AUTH parameter to the MAIL FROM command allows cooperating agents in a

75、trusted environment to communicate the authentication of individual messages.</p><p>　　If the server trusts the authenticated identity of the client to</p><p>　　assert that the message was origi

76、nally submitted by the supplied addr-spec, then the server SHOULD supply the same addr-spec in an AUTH parameter when relaying the message to any server which supports the AUTH extension.</p><p>　　A MAIL FRO

77、M parameter of AUTH=<> indicates that the original submitter of the message is not known. The server MUST NOT treat the message as having been originally submitted by the client.</p><p>　　If the AUTH p

78、arameter to the MAIL FROM is not supplied, the client has authenticated, and the server believes the message is an original submission by the client, the server MAY supply the client's identity in the addr-spec in an

79、 AUTH parameter when relaying the message to any server which supports the AUTH extension.</p><p>　　If the server does not sufficiently trust the authenticated identity of the client, or if the client is not

80、 authenticated, then the server MUST behave as if the AUTH=<> parameter was supplied. The server MAY, however, write the value of the AUTH parameter to a log file.</p><p>　　If an AUTH=<> paramete

81、r was supplied, either explicitly or due to the requirement in the previous paragraph, then the server MUST supply the AUTH=<> parameter when relaying the message to any server which it has authenticated to using t

82、he AUTH extension.</p><p>　　A server MAY treat expansion of a mailing list as a new submission, setting the AUTH parameter to the mailing list address or mailing list administration address when relaying the

83、 message to list subscribers.</p><p>　　It is conforming for an implementation to be hard-coded to treat all clients as being insufficiently trusted. In that case, the implementation does nothing more than pa

84、rse and discard syntactically valid AUTH parameters to the MAIL FROM command and supply AUTH=<> parameters to any servers to which it authenticates using the AUTH extension.</p><p><b>　　Examples:

85、</b></p><p>　　C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com</p><p><b>　　S: 250 OK</b></p><p>　　6. Error Codes</p><p>　　The following

86、 error codes may be used to indicate various conditions as described.</p><p>　　432 A password transition is needed</p><p>　　This response to the AUTH command indicates that the user needs to tra

87、nsition to the selected authentication mechanism. This typically done by authenticating once using the PLAIN authentication mechanism.</p><p>　　534 Authentication mechanism is too weak</p><p>　　

88、This response to the AUTH command indicates that the selected authentication mechanism is weaker than server policy permits for that user.</p><p>　　538 Encryption required for requested authentication mechan

89、ism</p><p>　　This response to the AUTH command indicates that the selected authentication mechanism may only be used when the underlying SMTP connection is encrypted.</p><p>　　454 Temporary auth

90、entication failure</p><p>　　This response to the AUTH command indicates that the authentication failed due to a temporary server failure.</p><p>　　530 Authentication required</p><p>

91、;　　This response may be returned by any command other than AUTH, EHLO, HELO, NOOP, RSET, or QUIT. It indicates that server policy requires authentication in order to perform the requested action.</p><p>　　7.

92、 Formal Syntax</p><p>　　The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [ABNF].</p><p>　　Except as noted otherwise, all alphabetic character

93、s are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.</p><p>　　UPA

94、LPHA = %x41-5A ;; Uppercase: A-Z</p><p>　　LOALPHA = %x61-7A ;; Lowercase: a-z</p><p>　　ALPHA = UPALPHA / LOALPHA ;; case insensitive</p><p>　　DIGIT = %x30-39 ;; Digits 0-9</p>

95、<p>　　HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)</p><p>　　hexchar = "+" HEXDIGIT HEXDIGIT</p><p>　　xchar = %x21-2A / %x2C-3C / %x3E-7E;; US-ASCII except for &qu

96、ot;+", "=", SPACE and CTL</p><p>　　xtext = *(xchar / hexchar)</p><p>　　AUTH_CHAR = ALPHA / DIGIT / "-" / "_"</p><p>　　auth_type = 1*20AUTH_CHAR<

97、;/p><p>　　auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]*(CRLF [base64]) CRLF</p><p>　　auth_param = "AUTH=" xtext;; The decoded form of the xtext MUST be

98、 either;; an addr-spec or the two characters "<>"</p><p>　　base64 = base64_terminal /( 1*(4base64_CHAR) [base64_terminal] )</p><p>　　base64_char = UPALPHA / LOALPHA / DIGIT / &qu

99、ot;+" / "/";; Case-sensitive</p><p>　　base64_terminal = (2base64_char "==") / (3base64_char "=")</p><p>　　continue_req = "334" SPACE [base64] CRLF<

100、;/p><p>　　CR = %x0C ;; ASCII CR, carriage return</p><p>　　CRLF = CR LF</p><p>　　CTL = %x00-1F / %x7F ;; any ASCII control character and DEL</p><p>　　LF = %x0A ;; ASCII LF,

101、 line feed</p><p>　　SPACE = %x20 ;; ASCII SP, space</p><p>　　8. References</p><p>　　[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC

102、2234, November 1997.</p><p>　　[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.</p><p>　　[ESMT

103、P] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC1869, November 1995.</p><p>　　[ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status

104、 Notifications", RFC1891, January 1996.</p><p>　　[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997</p><p>　　[SASL] My

105、ers, J., "Simple Authentication and Security Layer (SASL)", RFC2222, October 1997.</p><p>　　[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.</p>

106、<p>　　[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.</p><p>　　[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD

107、 11, RFC822, August 1982.</p><p>　　9. Security Considerations</p><p>　　Security issues are discussed throughout this memo.</p><p>　　If a client uses this extension to get an encrypt

108、ed tunnel through an insecure network to a cooperating server, it needs to be configured to never send mail to that server when the connection is not mutually authenticated and encrypted. Otherwise, an attacker could ste

109、al the client's mail by hijacking the SMTP connection and either pretending the server does not support the Authentication extension or causing all AUTH commands to fail.</p><p>　　Before the SASL negotia

110、tion has begun, any protocol interactions are performed in the clear and may be modified by an active attacker. For this reason, clients and servers MUST discard any knowledge obtained prior to the start of the SASL nego