1、譯文SMTP服務擴展的認證機制這個文檔詳細說明了因特網(wǎng)團體的一個標準的協(xié)議的發(fā)展，以及對其改進和建議提 出了要求。說到這，為了標準化這個協(xié)議的狀態(tài)和地位，就必須提及目前最新的“Internet 官方協(xié)議的標準”(STD1)。發(fā)送這個文檔是不受限制的。版權須知版權所有一1999年Internet團體。所有權利將得到保留。1簡介這個文檔定義了 SMTP服務的擴展(ESMTP)并且說明了一個SMTP客戶端可以 為服務器指定一種用來執(zhí)行與認證協(xié)議的交換，并且隨意地穿越并發(fā)的協(xié)議之間交互的 安全層的認證機制。這個擴展是“簡單認證和安全層” SASL的一個側面。2這個文檔用到的協(xié)定在以下的這些例子中，C和

2、S分別表示客戶端和服務器。諸如 MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY這些關鍵性 的單詞被可以看作和“用在RFC文檔中用來標示必須的級別的關鍵字 KEYWORDS 相同的解釋。3認證服務的擴展SMTP服務擴展的名稱是Authentication聯(lián)合這個擴展的EHLO關鍵字的值是“AUTH AUTH EHLO關鍵字 是一個有空格間隔的被SASL機制支持的名字列表的參數(shù)一個新的SMTP動詞“AUTH 定義完成。用在關鍵字 “AUTH “的一個可選的參數(shù)被附加到MAIL FROM命令里，用來指 定MAIL FROM命令一行的最大長度不能超過500個字符

3、。此擴展和委托協(xié)議兼容。4 AUTH命令AUTH機制初始化響應觀點：用來標識SASL認證機制的一個字符串可選的Base64編碼的一個響應約束：再成功發(fā)出了一個AUTH命令之后，在同一時間段里不能再執(zhí)行其他的AUTH命 令。在成功執(zhí)行了一個AUTH命令之后，服務器必須拒絕后來的AUTH命令并且返回 一個503響應碼。在處理一個郵件事務期間，服務器不會再接受AUTH命令。討論：AUTH命令顯示了一種和郵件服務器間的安全認證機制。如果郵件服務器支持這 種認證機制，它就會執(zhí)行一個認證協(xié)議交互來認證并識別郵件用戶。作為可選的情況， 他也會忽略這以后后協(xié)議交互的一個安全層。如果服務器并不支持所需要的認證協(xié)

4、議， 就會用504的回答來拒絕這個AUTH命令。這種認證機制的交互由一些列的服務器的響應和對認證機制來說的一些特殊的回 答來組成。服務器的正確響應，不同于其他的響應的是針對文本部分采用Base64編碼 以334做為回應的?？蛻舳说幕貞且粋€包含Base64編碼的字符串的隊列。如果客戶 端想取消與服務器的認證交互，就執(zhí)行一個單個的“*”。如果服務器接到這樣一個回應， 就通過發(fā)送一個501的響應來拒絕執(zhí)行AUTH命令。對AUTH命令來說，可選的初始化響應建議是用來在使用認證機制時保持一個往返的回程，認證機制的定義中此建議不發(fā)送任何數(shù)據(jù)。當初始化響應部分用在這種機 制時，開始的空的發(fā)起命令不被送到客

5、戶端，并且服務器端使用的數(shù)據(jù)也好象是發(fā)送來響應一個空的命令。它發(fā)送一個零長度的初始化回答作為一個符號。如果客戶 端在認證機制的AUTH命令響應中使用初始化建議，客戶端就在初始化命令中發(fā)送響 應的數(shù)據(jù)，服務器端用535回答來拒絕AUTH命令。如果服務器不能對發(fā)送來的命令采用Base64解碼的話，將拒絕執(zhí)行Auth命令，并 返回501響應。如果服務器拒絕認證的數(shù)據(jù)，服務器應該拒絕執(zhí)行并返回一個535響應 碼除非有更詳細的錯誤代碼，例如在Section 6列出來的那個。如果客戶端和服務器進行 了正確的交互的操作的話，SMTP服務器將發(fā)出一個235響應碼。詳細說明這個SASL側面的服務器的名稱是” S

6、MTP 。如果SASL認證交互穿越了一個安全層，將會通過一個有用來中止認證交互的 CRLF來產(chǎn)生效果，而服務器也通過一個CRLF做出正確的響應。在服務器的安全層生 效之前，SMTP協(xié)議被重置到初始狀態(tài)（SMTP中的狀態(tài)是服務器發(fā)出了一個220服務 的問候之后）。服務器MUST命令將拋棄所有的不是通過客戶端而得到的認知，比如不 是通過SASL本身而獲得認知的EHLO命令的論點?？蛻舳说腗UST命令將拋棄所有 的從服務器獲得的認知，例如不是通過SASL本身而獲得的SMTP服務擴展的隊列?？?戶端的SHOULD在SASL商議成功之后，發(fā)出一個EHLO命令做為第一個命令，這些 將使得安全層得到授權。服

7、務器不一定要求支持任何的認證機制，而認證機制也不一定要支持所有的安全 層。如果一個AUTH命令失敗了，客戶端將試圖執(zhí)行另一個認證機制的AUTH命令。一個Base64編碼的字符串通常來說是沒有長度限制的。只要由認證機制產(chǎn)生的受 客戶端和服務器支持的命令和響應，客戶端和服務器端必須支持，而不依賴于服務器或 者客戶端的、可能存在于協(xié)議實現(xiàn)的某些方面的行長度的限制。例如：Examples:S: 220 ESMTP server readyC: EHLO S: 250-S: 250 AUTH CRAM-MD5 DIGEST-MD5C: AUTH FOOBARS: 504 Unrecognized aut

8、hentication type.C: AUTH CRAM-MD5S: 334PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ=S: 235 Authentication successful.5.AUTH命令的參數(shù)附加到的MAIL FROM命令AUTH=addr-spec參數(shù):一個包含標志的被提交給傳送系統(tǒng)的addr-spec，或者是兩個字符組成的序 列,表明這個標志是未知的或被驗明為不完成的。討論：AUTH中一個可

9、選的參數(shù)的MAIL FROM命令允許一個協(xié)同工作的代理與一單獨 的消息就行通信在一個被信任的環(huán)境里。如果服務器認為最初提交消息的Addr-dec的客戶端是可信任的話，將會發(fā)出一個 聲明，接著服務器應當提供一個相同的addr-dec給任何其他支持AUTH擴展的用來中 轉消息的服務器。如果MAIL FROM命令中那個可選的AUTH命令的參數(shù)沒有得到提供的話，而客 戶端已經(jīng)得到認證，那么服務器認為消息是由客戶端提交的原始的信息，那么在中轉給 其他的中繼服務器的時候，當前服務器就會把addr-dec做為Auth命令的可選的參數(shù)提 供給其它的服務器。如果服務器不是充分的相信客戶端的身份或者客戶端并沒有得

10、到認證的話，那么服 務器必須自己提供AUTH命令的那個參數(shù)一個值。并且將這個值寫入到日志文件中。如果AUTH命令的可選的參數(shù)已經(jīng)提供了的話，不管是明確的提出還是由于前面段 落的需要，服務器應當提供這個參數(shù)給任何其他支持AUTH擴展的用來中轉消息的服務 器。服務器將把郵件列表的擴充視為一個新的任務，AUTH命令加入到郵件地址列表 中，或者在中轉這些消息到列表簽署者的時候管理郵件列表。為了一致，在一個執(zhí)行很難被編碼的時候，服務器將認為所有的這些客戶端都是不 可信任的。在這種情況下，服務器能做的僅僅就是解析有效的AUTH命令的參數(shù)，并把 它提供給任所有使用AUTH擴展的認證機制的服務器，并遺棄無效的

11、參數(shù)。例如：C: MAIL FROM: AUTH=e+ HYPERLINK mailto:3Dmc2 3Dmc2S: 250 OK6錯誤代碼以下的錯誤代碼常常用來描述和標識各種情況。第4頁共7頁432 需要進行密碼的轉換這個響應碼表示，對于服務器的認證機制來講，用戶必須進行一個轉換。比較由代 表性的就是一旦你使用了 PLAIN認證機制的話，就必須進行轉換。534認證機過于簡單這個響應碼表示的是選擇的認證機制相對于服務器所允許的認證機制來說顯得太 弱了。538請求的認證機制需要加密這個響應碼表示的是所選的認證機制只有在SMTP連接是需要加密的情況下才用 的著454暫時的認證失敗這個響應碼表示的是

12、認證失敗的原因是由于服務器暫時出現(xiàn)問題530認證是必須的除了 AUTH，EHLO, HELO, NOOP，RESET或者QUIT這幾個命令之外的任何一 個命令，都將返回這個響應碼。這表示服務器需要為了執(zhí)行被請求的操作，需要一個認 證。7正規(guī)的語法以下的用在擴展的BNF符號和用在ABNF中的語法的規(guī)格是一樣的。除了那些被標注的以外，所有的按字母順序排列的特征都是適合于固定場合的。排 在上面的或者下面的被用來定義為有象征意義的字符串的用處僅僅是為了編輯時的便 利以及清晰。執(zhí)行這些必須在以固定的格式在一定的場合來接受這些字符串。UPALPHA = %x41-5A ; Uppercase: A-ZLO

13、ALPHA = %x61-7A ; Lowercase: a-zALPHA = UPALPHA / LOALPHA ; case insensitiveDIGIT = %x30-39 ; Digits 0-9HEXDIGIT = %x41-46 / DIGIT ; hexidecimal digit (uppercase)hexchar = + HEXDIGIT HEXDIGITxchar = %x21-2A / %x2C-3C / %x3E-7E;US-ASCII except for +, =, SPACE and CTLxtext = *(xchar / hexchar)AUTH_CHA

14、R = ALPHA / DIGIT / - / _auth_type = 1*20AUTH_CHARauth_command = AUTH SPACE auth_type SPACE (base64 /=)*(CRLF base64) CRLFauth_param = AUTH= xtext;The decoded form of the xtext MUST be either;an addr-spec or the two characters base64 = base64_terminal /(1*(4base64_CHAR) base64_terminal)base64_char =

15、 UPALPHA / LOALPHA / DIGIT / + / /;Case-sensitivebase64_terminal = (2base64_char =) / (3base64_char =)continue_req = 334 SPACE base64 CRLFCR = %x0C ; ASCII CR, carriage returnCRLF = CR LFCTL = %x00-1F / %x7F ; any ASCII control character and DELLF = %x0A ; ASCII LF, line feedSPACE = %x20 ; ASCII SP,

16、 space9安全問題考慮如果客戶端使用這個擴展得到不加密的渠道但是通過一個不安全的網(wǎng)絡連接到協(xié) 同工作的服務器的話，客戶端將被阻斷而永遠不能發(fā)送郵件到服務器，當服務器不能夠 互助地進行驗證和加密的時候。否則，攻擊者將會通過截斷SMTP的連接而偷取客戶端 的信件，或者假裝服務器不支持認證，從而導致所有的AUTH命令失敗。在SASL商議開始之前，任何協(xié)議之間的交互都可以暢通無阻的進行，但也有可能 被活動著的攻擊者修改。因此客戶端和服務器都必須拋棄在SASL之前獲得的所有消息。認證機制并不保護 TCP端口，攻擊者就會通過修改中轉的連接而試圖連接(SUBMIT)o AUTH命令的參數(shù)就可以阻止這種攻擊。一個消息子服務客戶端可能會要求用戶通過驗證，在任何它得到一個合適的SASL 的時候。因此，對于一個聲明SASL機制的SUBMIT來說并不是合算的，在使用一個同意