1.簡介

本文檔定義擴(kuò)展郵件服務(wù),一個(gè)SMTP(簡單郵件傳輸協(xié)議)的客戶端和服務(wù)器之間可以存
在一種認(rèn)證機(jī)制，執(zhí)行認(rèn)證協(xié)議的交互，并為以后的郵件協(xié)議交互進(jìn)行安全層次的協(xié)商。這
個(gè)擴(kuò)展是SASL(簡單認(rèn)證與安全層)的一個(gè)方面。


2.本文檔中的約定
在示例中，“c:”和“s:”分別代表了客戶端和服務(wù)器端發(fā)送的數(shù)據(jù)行。

本文中，要害詞MUST","MUSTNOT","SHOULD","SHOULDNOT","MAY"和"Key
WordsforuseinRFCstoIndicateRequirementLevels"中的定義一致。

3.驗(yàn)證服務(wù)擴(kuò)展

(1)這種SMTP擴(kuò)展服務(wù)的名稱是“認(rèn)證”。

(2)和本擴(kuò)展服務(wù)關(guān)聯(lián)的EHLO要害字的值是“AUTH”

(3)AUTHEHLO要害字是一個(gè)有空格間隔的被SASL機(jī)制支持的名字列表的參數(shù)。

(4)定義了一個(gè)新的SMTP協(xié)議的命令詞AUTH。

(5)要害詞AUTH被用做一個(gè)可選的參數(shù)被加入MAILFORM命令中并把MAILFROM
命令行的的最大長度擴(kuò)展到500個(gè)ansi字符。

(6)此擴(kuò)展和委托協(xié)議兼容（thesubmissionPRotocol[SUBMIT]）。


4.AUTH命令

AUTH機(jī)制[初始化響應(yīng)]

參數(shù)：
判別是一個(gè)SASL認(rèn)證機(jī)制的字符串。

可選的由base64編碼的響應(yīng)。

約束：
在一個(gè)AUTH命令完整結(jié)束后，本次會話就不再有其他的AUTH命令涉及了。
就是說，在一個(gè)成功的AUTH命令后，SMTP服務(wù)器用503標(biāo)識的回應(yīng)來拒絕任何以后的
AUTH命令。

在一個(gè)郵件傳輸過程中發(fā)出的AUTH命令是不被容許的。

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

認(rèn)證協(xié)議交互過程由一系列由認(rèn)證機(jī)制定義的郵件服務(wù)器端的命令和郵件客戶端
的響應(yīng)組成。

一個(gè)郵件服務(wù)器端命令，或者所謂一個(gè)預(yù)備好響應(yīng)，是一個(gè)334起頭的，包含用
base64編碼的字符串文本。郵件客戶端也同樣由包含了用base64編碼的字符串。假如郵件
客戶端希望可以取消一個(gè)進(jìn)行中的認(rèn)證交互過程，它會發(fā)出一個(gè)僅包含一個(gè)字符"*"命令行，
郵件服務(wù)器端一旦收到這樣的一個(gè)回答后，必須發(fā)一個(gè)501標(biāo)識的回答，而后拒絕AUTH
命令。
對AUTH命令來說，可選的初始化響應(yīng)建議是用來在使用認(rèn)證機(jī)制時(shí)保持一個(gè)往
返的回程,認(rèn)證機(jī)制的定義中此建議不發(fā)送任何數(shù)據(jù)。當(dāng)初始化響應(yīng)部分用在這種機(jī)制時(shí)，
開始的空的發(fā)起命令不被送到客戶端，并且服務(wù)器端使用的數(shù)據(jù)也好象是發(fā)送來
響應(yīng)一個(gè)空的命令。它發(fā)送一個(gè)零長度的初始化回答作為一個(gè)"="符號。假如客戶端
在認(rèn)證機(jī)制的AUTH命令響應(yīng)中使用初始化建議，客戶端就在初始化命令中發(fā)送響應(yīng)的
數(shù)據(jù)，服務(wù)器端用535回答來拒絕AUTH命令。

假如不能對參數(shù)用base64解碼，就用501回答來拒絕AUTH命令，假如服務(wù)器
拒絕認(rèn)證數(shù)據(jù)，它應(yīng)該用535的回答（可以帶其他具體的非凡錯(cuò)誤代碼，比如在第6節(jié)所列
的代碼中的一個(gè)）來拒絕AUTH命令。假如客戶端成功完成了認(rèn)證交互，SMTP服務(wù)器就
應(yīng)該返回一個(gè)235的響應(yīng)。
本SASL協(xié)議梗概中描述的服務(wù)名稱是SMTP.

假如一個(gè)安全層通過了SASL認(rèn)證交換，隨著作為終止客戶端認(rèn)證交換的CRLF
（回車換行），這個(gè)安全層立即有效。在安全層起作用后，其上的SMTP協(xié)議被復(fù)位到初試
狀態(tài)（這個(gè)SMTP狀態(tài)是在服務(wù)器發(fā)出一個(gè)220服務(wù)預(yù)備好的消息后開始的）。接著服務(wù)器
就會放棄所有來自客戶端的知識，例如，不是獲得自SASL協(xié)商本身的EHLO命令的參數(shù)。
客戶端也會放棄所有來自服務(wù)器端的知識，例如，不是獲得自SASL協(xié)商本身的SMTP擴(kuò)
展服務(wù)（這里假設(shè)一個(gè)客戶端可以比較認(rèn)證前后的建議的SASL機(jī)制的列表，從而檢測主動
down-negotiation攻擊）。客戶端應(yīng)該發(fā)出一個(gè)EHLO命令，此命令作為使一個(gè)安全層有效的
認(rèn)證協(xié)商成功后的第一個(gè)命令。
服務(wù)器并不被要求一定支持任何特定的認(rèn)證機(jī)制，同樣認(rèn)證機(jī)制要不要求必須支
持某種安全層。
一旦一個(gè)AUTH命令失敗，客戶端可以通過發(fā)出另外一個(gè)AUTH命令來嘗試其
他一種認(rèn)證機(jī)制。
一旦一個(gè)AUTH命令失敗，服務(wù)器端的行為就好象客戶端從沒有發(fā)出那次AUTH
命令一樣。

base64編碼的字符串一般可以有任意長度。客戶端和服務(wù)器端都應(yīng)該可以支持
那些由認(rèn)證機(jī)制產(chǎn)生的合法的任意長的請求和響應(yīng)字符串，而不依靠于服務(wù)器或者客戶端
的、可能存在于協(xié)議實(shí)現(xiàn)的某些方面的行長度的限制。

例如：
S:220SMTP.example.comESMTPserverready
C:EHLOjgm.example.com
S:250-SMTP.example.com
S:250AUTHCRAM-md5DIGEST-MD5
C:AUTHFoobar
S:504UnrecognizedAUTHenticationtype.
C:AUTHCRAM-MD5
S:334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvBT4=
C:ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S:235AuthenticationsUCcessful.


5.對應(yīng)MAILfrom命令的AUTH參數(shù)

AUTH=addr-spec

參數(shù)：
一個(gè)包含標(biāo)志的被提交給傳送系統(tǒng)的addr-spec，或者是兩個(gè)字符組成的序列"<>",
表明這個(gè)標(biāo)志是未知的或被驗(yàn)明為不完成的。

為了遵守附加在eSMTP參數(shù)上的限制，addr-spec被編碼到一個(gè)xtext中，關(guān)于xtext
語法的描述在[eSMTP-dsn]中的第5節(jié)中。

討論：
對應(yīng)MAILfrom命令的可選的AUTH參數(shù)容許在一個(gè)可以信賴的環(huán)境中多代理
合作來傳送個(gè)人消息的認(rèn)證。

假如服務(wù)器信任客戶端的被驗(yàn)證的標(biāo)志（這個(gè)標(biāo)志表明這個(gè)消息最初是由給定的
addr-spec提交的），則當(dāng)需要把消息轉(zhuǎn)發(fā)到任何支持AUTH擴(kuò)展的服務(wù)器去的時(shí)候，服務(wù)器
應(yīng)該用包含相同的addr-spec參數(shù)的AUTH命令往返復(fù)。

一個(gè)MAILFORM參數(shù)AUTH=<>顯示最初提交的信息是未知的。服務(wù)器端并不把
這個(gè)消息作為由客戶端的初始提交數(shù)據(jù)對待。
假如MAILFORM的AUTH參數(shù)沒有提供，客戶端已經(jīng)被驗(yàn)證，并且服務(wù)器端相信
消息
是原始的客戶端的提交，則當(dāng)需要把消息轉(zhuǎn)發(fā)到任何支持AUTH擴(kuò)展的服務(wù)器去的
時(shí)候，
服務(wù)器端應(yīng)該在AUTH參數(shù)的中的add-spe里提供客戶端標(biāo)記。

假如服務(wù)器端不是充分信任客戶端的認(rèn)證標(biāo)志，或者客戶端沒有通過認(rèn)證，則服務(wù)
器端會表現(xiàn)為似乎由一個(gè)AUTH=<>參數(shù)被提交一樣。服務(wù)器端也可以把a(bǔ)hth的參數(shù)寫入到
一個(gè)log文件中去。

假如提交一個(gè)AUTH=<>參數(shù)，不管是明確提供還是由于在上面段落中的條件隱含
提供，服務(wù)器端在轉(zhuǎn)發(fā)消息到用AUTH擴(kuò)展認(rèn)證的其他任何服務(wù)器的時(shí)候都必須提供
AUTH=<>的參數(shù)。

一個(gè)服務(wù)器應(yīng)該把郵件列表擴(kuò)展作為一個(gè)新的子任務(wù)來對待，在轉(zhuǎn)發(fā)消息到列表訂
戶的時(shí)候，為郵件列表地址或郵件列表治理設(shè)置AUTH參數(shù)。
一個(gè)“硬編碼”的實(shí)現(xiàn)是把所有客戶端都當(dāng)作不完全信任的。這時(shí)，這個(gè)實(shí)現(xiàn)只是
解析并拋棄語法有效的mialfrom命令的AUTH參數(shù)并提供AUTH=<>參數(shù)給任何用AUTH
擴(kuò)展來做認(rèn)證的服務(wù)器。

例如：
C:MAILFROM:<e=mc2@example.com>AUTH=e+3Dmc2@example.com
S:250OK
6.錯(cuò)誤代碼
以下的錯(cuò)誤代碼可以被用來顯示被描述的幾種情況。

432需要一個(gè)密碼轉(zhuǎn)換

這個(gè)對于AUTH命令的響應(yīng)顯示用戶需要轉(zhuǎn)換到被選擇的認(rèn)證機(jī)制。使用PLAIN認(rèn)證
機(jī)制時(shí)會這樣做。

534認(rèn)證機(jī)制過于簡單

這個(gè)對于AUTH命令的響應(yīng)顯示被選擇的認(rèn)證機(jī)制比服務(wù)器安全政策所許可此用戶的等
級要低。

538當(dāng)前請求的認(rèn)證機(jī)制需要加密

這個(gè)對于AUTH命令的響應(yīng)顯示當(dāng)前的認(rèn)證機(jī)制必須在SMTP連接被加密的情況下才
可以使用。

454臨時(shí)認(rèn)證失敗

這個(gè)對于AUTH命令的響應(yīng)顯示因?yàn)榕R時(shí)服務(wù)器出錯(cuò)而導(dǎo)致認(rèn)證失敗

530需要認(rèn)證

這個(gè)響應(yīng)可以被任何命令返回（除了AUTH,EHLO,HELO,NOOP,RSET,或QUIT）。
它表明服務(wù)器安全策略要求認(rèn)證以執(zhí)行客戶端的請求動作。
7.正式的語法
下面的語法定義使用了擴(kuò)展的Backus-NaurForm(BNF)符號，它的具體說明在[abfn]。
除了有名的另外的方式，所有的字母表字符都是大小寫不敏感的。這里使用大寫或小
寫字符來定義要害字符串只是為了編輯上的清楚。具體實(shí)現(xiàn)必須把這些字符串做為大小
寫不敏感的方式來接受。

UPALPHA=%x41-5A;;Uppercase:A-Z

LOALPHA=%x61-7A;;Lowercase:a-z

ALPHA=UPALPHA/LOALPHA;;caseinsensitive

DIGIT=%x30-39;;Digits0-9

HEXDIGIT=%x41-46/DIGIT;;hexidecimaldigit(uppercase)

hexchar="+"HEXDIGITHEXDIGIT

xchar=%x21-2A/%x2C-3C/%x3E-7E
;;US-ASCIIexceptfor"+","=",SPACEandCTL

xtext=*(xchar/hexchar)

AUTH_CHAR=ALPHA/DIGIT/"-"/"_"

AUTH_type=1*20AUTH_CHAR

AUTH_command="AUTH"SPACEAUTH_type[SPACE(base64/"=")]
*(CRLF[base64])CRLF

AUTH_param="AUTH="xtext
;;ThedecodedFORMofthextextMUSTbeeither
;;anaddr-specorthetwocharacters"<>"

base64=base64_terminal/
(1*(4base64_CHAR)[base64_terminal])

base64_char=UPALPHA/LOALPHA/DIGIT/"+"/"/"
;;Case-sensitive

base64_terminal=(2base64_char"==")/(3base64_char"=")

continue_req="334"SPACE[base64]CRLF


CR=%x0C;;ASCIICR,carriagereturn

CRLF=CRLF

CTL=%x00-1F/%x7F;;anyASCIIcontrolcharacterandDEL

LF=%x0A;;ASCIILF,linefeed

SPACE=%x20;;ASCIISP,space




8.References

[ABNF]Crocker,D.andP.Overell,"AugmentedBNFforSyntax
Specifications:ABNF",RFC2234,November1997.

[CRAM-MD5]Klensin,J.,Catoe,R.andP.Krumviede,"IMAP/POP
AUTHorizeExtensionforSimpleChallenge/Response",RFC
2195,September1997.

[ESMTP]Klensin,J.,Freed,N.,Rose,M.,Stefferud,E.andD.
Crocker,"SMTPServiceExtensions",RFC1869,November
1995.

[ESMTP-DSN]Moore,K,"SMTPServiceExtensionforDeliveryStatus
Notifications",RFC1891,January1996.

[KEYWORDS]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.

[SASL]Myers,J.,"SimpleAuthenticationandSecurityLayer
(SASL)",RFC2222,October1997.

[SUBMIT]Gellens,R.andJ.Klensin,"MessageSubmission",RFC
2476,December1998.

[RFC821]Postel,J.,"SimpleMailTransferProtocol",STD10,RFC
821,August1982.

[RFC822]Crocker,D.,"StandardfortheFormatofARPAInternet
TextMessages",STD11,RFC822,August1982.



9.安全上的考慮

這里探討有關(guān)安全的主題。

假如客戶端使用這種擴(kuò)展來得到一個(gè)通過一個(gè)不安全的網(wǎng)絡(luò)到達(dá)與之合作的服務(wù)器
的加密信道，同時(shí)連接沒有被交互認(rèn)證和加密，它需要被配置為從沒有向這個(gè)服務(wù)器發(fā)送郵
件。否則一個(gè)攻擊者可以通過截獲SMTP連接并假裝服務(wù)器不能支持認(rèn)證擴(kuò)展或讓所有
AUTH命令失敗的方式偷走用戶的郵件。

在SASL協(xié)商發(fā)生之前，任何協(xié)議交互數(shù)據(jù)都是明文而且可以被一個(gè)主動攻擊者更改，
因此，客戶端和服務(wù)器端都應(yīng)該拋棄在SASL協(xié)商開始前的獲得的信息。

這種機(jī)制不保護(hù)tcp端口，所以主動進(jìn)攻者可以把一個(gè)轉(zhuǎn)發(fā)連接重定向到委托端口。
AUTH=<>參數(shù)防止這種導(dǎo)致轉(zhuǎn)發(fā)沒有認(rèn)證消息以恢復(fù)轉(zhuǎn)發(fā)客戶端的認(rèn)證的攻擊。

一個(gè)消息托付客戶端可以要求用戶不管是否被告之一個(gè)適當(dāng)?shù)腟ASL機(jī)制都必須認(rèn)證。
因此，對一個(gè)委托服務(wù)器來說，去建議一個(gè)SASL機(jī)制使不合適的，使用這種機(jī)制通過匿名
委托給客戶端不會帶來任何的益處。

這種擴(kuò)展不是為了取代類似s/mime或pgp的端到端的消息簽名和加密系統(tǒng)。它和端到
端系統(tǒng)要解決的問題不同。有以下主要的區(qū)別：

(1)它一般只在被信任的環(huán)境中有效。

(2)它保護(hù)整個(gè)消息的報(bào)頭部分，而不是郵件消息的主體部分。

(3)它對消息委托進(jìn)行認(rèn)證，而不是對消息內(nèi)容的作者的認(rèn)證。

(4)它可以給發(fā)送者一定的保證：在發(fā)送者交互認(rèn)證并協(xié)商了一個(gè)合適的安全層的情
況下，這個(gè)消息確信被傳遞到了下一跳。

其他有關(guān)安全問題的事項(xiàng)在SASL規(guī)范中有論述。


10作者地址

JohnGardinerMyers
NetscapeCommunications
501EastMiddlefieldRoad
MailStopMV-029
MountainView,CA94043

EMail:jgmyers@netscape.com


11.FullCopyrightStatement

Copyright(C)TheInternetSociety(1999).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

ThisdocumentandtheinFORMationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.