【導(dǎo)讀】words"MUST","MUSTNOT","SHOULD","SHOULDNOT",and"MAY"inthisdocument. [KEYWORDS].characters.

　　

【正文】 端和服務(wù)器進(jìn)行了正確的交互的操作的話(huà)， SMTP服務(wù)器將發(fā)出一個(gè) 235響應(yīng)碼。 詳細(xì)說(shuō)明這個(gè) SASL側(cè)面的服務(wù)器的名稱(chēng)是” SMTP“。 如果 SASL 認(rèn)證交互穿越了一個(gè)安全層，將會(huì)通過(guò)一個(gè)有用來(lái)中止認(rèn)證交互的CRLF來(lái)產(chǎn)生效果，而服務(wù)器也通過(guò)一個(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è)命令，這些將使得安全層得到授權(quán)。 服務(wù)器不一定要求支持任何的認(rèn)證機(jī)制，而認(rèn)證機(jī)制也不一定要支持所有的安全層。如果一個(gè) AUTH命令失敗了，客戶(hù)端將試圖執(zhí)行另一個(gè)認(rèn)證機(jī)制的 AUTH命令。 一個(gè) Base64 編碼的字符串通常來(lái)說(shuō)是沒(méi)有長(zhǎng)度限制的。只要由認(rèn)證機(jī)制產(chǎn) 生的受客戶(hù)端和服務(wù)器支持的命令和響應(yīng)，客戶(hù)端和服務(wù)器端必須支持，而不依賴(lài)于服務(wù)器或者客戶(hù)端的、可能存在于協(xié)議實(shí)現(xiàn)的某些方面的行長(zhǎng)度的限制。 例如： Examples: S: 220 ESMTP server ready C: EHLO S: S: 250 AUTH CRAMMD5 DIGESTMD5 C: AUTH FOOBAR S: 504 Unrecognized authentication type. C: AUTH CRAMMD5 S: 334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== S: 235 Authentication successful. 5. AUTH命令的參數(shù)附加到的 MAIL FROM命令 AUTH=addrspec 參數(shù)： 一個(gè)包含標(biāo)志的被提交給傳送系統(tǒng)的 addrspec，或者是兩個(gè)字符組成的序列 , 表明這個(gè)標(biāo)志是未知的或被驗(yàn)明為不完成的。 討論： AUTH 中一個(gè)可選的參數(shù)的 MAIL FROM 命令允許一個(gè)協(xié)同工作的代理與一單獨(dú)的消息就行通信在一個(gè)被信任的環(huán)境里。 如果服務(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ù)器。 如果 MAIL FROM 命令中那個(gè)可選的 AUTH 命令的參數(shù)沒(méi)有得到提供的話(huà)，而客戶(hù)端已經(jīng)得到認(rèn)證，那么服務(wù)器認(rèn)為消息是由客戶(hù)端提交的原始的信息，那么在中轉(zhuǎn)給其他的中繼服務(wù)器的時(shí)候，當(dāng)前服務(wù)器就會(huì)把 addr－ dec做為 Auth命令的可選的參數(shù)提供給其它的服務(wù)器。 如果服務(wù)器不是充分的相信客戶(hù)端的身份或者客戶(hù)端并沒(méi)有得到認(rèn)證的話(huà)，那么服務(wù)器必須自己提供 AUTH命令的那個(gè)參數(shù)一個(gè)值。并且將這個(gè)值寫(xiě)入到日志文件中。 如果 AUTH命令的可選的參數(shù)已經(jīng)提供了的話(huà)，不管是明確的提出還是由于前面段落的需要，服務(wù)器應(yīng)當(dāng)提供這個(gè) 參數(shù)給任何其他支持 AUTH擴(kuò)展的用來(lái)中轉(zhuǎn)消息的服務(wù)器。 服務(wù)器將把郵件列表的擴(kuò)充視為一個(gè)新的任務(wù)， AUTH 命令加入到郵件地址列表中，或者在中轉(zhuǎn)這些消息到列表簽署者的時(shí)候管理郵件列表。 為了一致，在一個(gè)執(zhí)行很難被編碼的時(shí)候，服務(wù)器將認(rèn)為所有的這些客戶(hù)端都是不可信任的。在這種情況下，服務(wù)器能做的僅僅就是解析有效的 AUTH命令的參數(shù)，并把它提供給任所有使用 AUTH擴(kuò)展的認(rèn)證機(jī)制的服務(wù)器，并遺棄無(wú)效的參數(shù)。 例如： C: MAIL FROM: S: 250 OK 6 錯(cuò)誤代碼 以下的錯(cuò)誤代碼常常用來(lái)描述和標(biāo)識(shí)各種情況。 432 需要進(jìn)行密碼的轉(zhuǎn)換 這個(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)換。 534 認(rèn)證機(jī)過(guò)于簡(jiǎn)單 這個(gè)響應(yīng)碼表示的是選擇的認(rèn)證機(jī)制相對(duì)于服務(wù)器所允許的認(rèn)證機(jī)制來(lái)說(shuō)顯得太弱了。 538 請(qǐng)求的認(rèn)證機(jī)制需要加密 這個(gè)響應(yīng)碼表示的是所選的認(rèn)證機(jī)制只有在 SMTP 連接是需要加密的情況下才用的著 454 暫時(shí)的認(rèn)證失敗 這個(gè)響 應(yīng)碼表示的是認(rèn)證失敗的原因是由于服務(wù)器暫時(shí)出現(xiàn)問(wèn)題 530 認(rèn)證是必須的 除了 AUTH， EHLO， HELO， NOOP， RESET或者 QUIT這幾個(gè)命令之外的任何一個(gè)命令，都將返回這個(gè)響應(yīng)碼。這表示服務(wù)器需要為了執(zhí)行被請(qǐng)求的操作，需要一個(gè)認(rèn)證。 7 正規(guī)的語(yǔ)法 以下的用在擴(kuò)展的 BNF符號(hào)和用在 ABNF中的語(yǔ)法的規(guī)格是一樣的。 除了那些被標(biāo)注的以外，所有的按字母順序排列的特征都是適合于固定場(chǎng)合的。排在上面的或者下面的被用來(lái)定義為有象征意義的字符串的用處僅僅是為了編輯時(shí)的便利以及清晰。執(zhí)行這些必須在以固定的格 式在一定的場(chǎng)合來(lái)接受這些字符串。 UPALPHA = %x415A 。 Uppercase: AZ LOALPHA = %x617A 。 Lowercase: az ALPHA = UPALPHA / LOALPHA 。 case insensitive DIGIT = %x3039 。 Digits 09 HEXDIGIT = %x4146 / DIGIT 。 hexidecimal digit (uppercase) hexchar = + HEXDIGIT HEXDIGIT xchar = %x212A / %x2C3C / %x3E7E 。 USASCII except for +, =, SPACE and CTL xtext = *(xchar / hexchar) AUTH_CHAR = ALPHA / DIGIT / / _ auth_type = 1*20AUTH_CHAR auth_mand = AUTH SPACE auth_type [SPACE (base64 / =)] *(CRLF [base64]) CRLF auth_param = AUTH= xtext 。 The decoded form of the xtext MUST be either 。 an addrspec or the two characters base64 = base64_terminal / ( 1*(4base64_CHAR) [base64_terminal] ) base64_char = UPALPHA / LOALPHA / DIGIT / + / / 。 Casesensitive base64_terminal = (2base64_char ==) / (3base64_char =) continue_req = 334 SPACE [base64] CRLF CR = %x0C 。 ASCII CR, carriage return CRLF = CR LF CTL = %x001F / %x7F 。 any ASCII control character and DEL LF = %x0A 。 ASCII LF, line feed SPACE = %x20 。 ASCII SP, space 9 安全問(wèn)題考慮 如果客戶(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)?SMTP的連接而偷取客戶(hù)端的信件，或者假裝服務(wù)器不支持認(rèn)證，從而導(dǎo)致所有的 AUTH命令失敗。 在 SASL商議開(kāi)始之前，任何協(xié)議之間的交互都可以暢通無(wú)阻的進(jìn)行，但也有可能被活動(dòng)著的攻擊者修改。因此客戶(hù)端和服務(wù)器都必須拋棄在 SASL之前獲得的所有消息。 認(rèn) 證機(jī)制并不保護(hù) TCP 端口，攻擊者就會(huì)通過(guò)修改中轉(zhuǎn)的連接而試圖連接（ SUBMIT）。 AUTH命令的參數(shù)就可以阻止這種攻擊。 一個(gè)消息子服務(wù)客戶(hù)端可能會(huì)要求用戶(hù)通過(guò)驗(yàn)證，在任何它得到一個(gè)合適的 SASL的時(shí)候。 因此，對(duì)于一個(gè)聲明 SASL機(jī)制的 SUBMIT來(lái)說(shuō)并不是合算的，在使用一個(gè)同意匿名子任務(wù)的客戶(hù)端而沒(méi)有任何利益的機(jī)制的時(shí)候。 這個(gè)擴(kuò)展并不是有意的取代或者被用來(lái)取代端到端的消息簽名在加密系統(tǒng) S/MIME或者 PGP中。此擴(kuò)展和端到端的系統(tǒng)有一些細(xì)微的差別，主要是以下的部分。 （ 1）它通常只在一個(gè)被信任的范圍里 有效 （ 2）它保護(hù)整個(gè)消息的封裝替，而不僅僅是正文 （ 3）它鑒證消息的子任務(wù)而不是消息的內(nèi)容 （ 4）在發(fā)信者協(xié)同驗(yàn)證下一個(gè)中轉(zhuǎn)點(diǎn)并且穿越一個(gè)合理的安全層的情況下，它可以給發(fā)信者一個(gè)保證，那就是可以把消息安全地傳遞到下一個(gè)地點(diǎn)。 另外需要說(shuō)明的是，安全問(wèn)題的考慮在 SASL說(shuō)明里面也有提到。