1.简介
本文档定义扩展邮件服务,一个SMTP(简单邮件传输协议)的客户端和服务器之间可以存
在一种认证机制，执行认证协议的交互，并为以后的邮件协议交互进行安全层次的协商。这
个扩展是SASL(简单认证与安全层)的一个方面。

2.本文档中的约定
在示例中，“c:”和“s:”分别代表了客户端和服务器端发送的数据行。
本文中，要害词MUST","MUSTNOT","SHOULD","SHOULDNOT","MAY"和"Key
WordsforuseinRFCstoIndicateRequirementLevels"中的定义一致。
3.验证服务扩展
(1)这种SMTP扩展服务的名称是“认证”。
(2)和本扩展服务关联的EHLO要害字的值是“AUTH”
(3)AUTHEHLO要害字是一个有空格间隔的被SASL机制支持的名字列表的参数。
(4)定义了一个新的SMTP协议的命令词AUTH。
(5)要害词AUTH被用做一个可选的参数被加入MAILFORM命令中并把MAILFROM
命令行的的最大长度扩展到500个ansi字符。
(6)此扩展和委托协议兼容（thesubmissionprotocol[SUBMIT]）。

4.AUTH命令
AUTH机制[初始化响应]
参数：
判别是一个SASL认证机制的字符串。
可选的由base64编码的响应。
约束：
在一个AUTH命令完整结束后，本次会话就不再有其他的AUTH命令涉及了。
就是说，在一个成功的AUTH命令后，SMTP服务器用503标识的回应来拒绝任何以后的
AUTH命令。
在一个邮件传输过程中发出的AUTH命令是不被容许的。
讨论：
AUTH命令显示了一种和邮件服务器间的安全认证机制。假如邮件服务器支持这
种认证机制，它就会执行一个认证协议交互来认证并识别邮件用户。作为可选的情况，他也
会忽略这以后后协议交互的一个安全层。假如服务器并不支持所需要的认证协议，就会用
504的回答来拒绝这个AUTH命令。
认证协议交互过程由一系列由认证机制定义的邮件服务器端的命令和邮件客户端
的响应组成。
一个邮件服务器端命令，或者所谓一个预备好响应，是一个334起头的，包含用
base64编码的字符串文本。邮件客户端也同样由包含了用base64编码的字符串。假如邮件
客户端希望可以取消一个进行中的认证交互过程，它会发出一个仅包含一个字符"*"命令行，
邮件服务器端一旦收到这样的一个回答后，必须发一个501标识的回答，而后拒绝AUTH
命令。
对AUTH命令来说，可选的初始化响应建议是用来在使用认证机制时保持一个往
返的回程,认证机制的定义中此建议不发送任何数据。当初始化响应部分用在这种机制时，
开始的空的发起命令不被送到客户端，并且服务器端使用的数据也好象是发送来
响应一个空的命令。它发送一个零长度的初始化回答作为一个"="符号。假如客户端
在认证机制的AUTH命令响应中使用初始化建议，客户端就在初始化命令中发送响应的
数据，服务器端用535回答来拒绝AUTH命令。
假如不能对参数用base64解码，就用501回答来拒绝AUTH命令，假如服务器
拒绝认证数据，它应该用535的回答（可以带其他具体的非凡错误代码，比如在第6节所列
的代码中的一个）来拒绝AUTH命令。假如客户端成功完成了认证交互，SMTP服务器就
应该返回一个235的响应。
本SASL协议梗概中描述的服务名称是SMTP.
假如一个安全层通过了SASL认证交换，随着作为终止客户端认证交换的CRLF
（回车换行），这个安全层立即有效。在安全层起作用后，其上的SMTP协议被复位到初试
状态（这个SMTP状态是在服务器发出一个220服务预备好的消息后开始的）。接着服务器
就会放弃所有来自客户端的知识，例如，不是获得自SASL协商本身的EHLO命令的参数。
客户端也会放弃所有来自服务器端的知识，例如，不是获得自SASL协商本身的SMTP扩
展服务（这里假设一个客户端可以比较认证前后的建议的SASL机制的列表，从而检测主动
down-negotiation攻击）。客户端应该发出一个EHLO命令，此命令作为使一个安全层有效的
认证协商成功后的第一个命令。
服务器并不被要求一定支持任何特定的认证机制，同样认证机制要不要求必须支
持某种安全层。
一旦一个AUTH命令失败，客户端可以通过发出另外一个AUTH命令来尝试其
他一种认证机制。
一旦一个AUTH命令失败，服务器端的行为就好象客户端从没有发出那次AUTH
命令一样。
base64编码的字符串一般可以有任意长度。客户端和服务器端都应该可以支持
那些由认证机制产生的合法的任意长的请求和响应字符串，而不依靠于服务器或者客户端
的、可能存在于协议实现的某些方面的行长度的限制。
例如：
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.对应MAILfrom命令的AUTH参数
AUTH=addr-spec
参数：
一个包含标志的被提交给传送系统的addr-spec，或者是两个字符组成的序列"<>",
表明这个标志是未知的或被验明为不完成的。
为了遵守附加在eSMTP参数上的限制，addr-spec被编码到一个xtext中，关于xtext
语法的描述在[eSMTP-dsn]中的第5节中。
讨论：
对应MAILfrom命令的可选的AUTH参数容许在一个可以信赖的环境中多代理
合作来传送个人消息的认证。
假如服务器信任客户端的被验证的标志（这个标志表明这个消息最初是由给定的
addr-spec提交的），则当需要把消息转发到任何支持AUTH扩展的服务器去的时候，服务器
应该用包含相同的addr-spec参数的AUTH命令往返复。
一个MAILFORM参数AUTH=<>显示最初提交的信息是未知的。服务器端并不把
这个消息作为由客户端的初始提交数据对待。
假如MAILFORM的AUTH参数没有提供，客户端已经被验证，并且服务器端相信
消息
是原始的客户端的提交，则当需要把消息转发到任何支持AUTH扩展的服务器去的
时候，
服务器端应该在AUTH参数的中的add-spe里提供客户端标记。
假如服务器端不是充分信任客户端的认证标志，或者客户端没有通过认证，则服务
器端会表现为似乎由一个AUTH=<>参数被提交一样。服务器端也可以把ahth的参数写入到
一个log文件中去。
假如提交一个AUTH=<>参数，不管是明确提供还是由于在上面段落中的条件隐含
提供，服务器端在转发消息到用AUTH扩展认证的其他任何服务器的时候都必须提供
AUTH=<>的参数。
一个服务器应该把邮件列表扩展作为一个新的子任务来对待，在转发消息到列表订
户的时候，为邮件列表地址或邮件列表治理设置AUTH参数。
一个“硬编码”的实现是把所有客户端都当作不完全信任的。这时，这个实现只是
解析并抛弃语法有效的mialfrom命令的AUTH参数并提供AUTH=<>参数给任何用AUTH
扩展来做认证的服务器。
例如：
C:MAILFROM:<e=mc2@example.com>AUTH=e+3Dmc2@example.com
S:250OK
6.错误代码
以下的错误代码可以被用来显示被描述的几种情况。
432需要一个密码转换
这个对于AUTH命令的响应显示用户需要转换到被选择的认证机制。使用PLAIN认证
机制时会这样做。
534认证机制过于简单
这个对于AUTH命令的响应显示被选择的认证机制比服务器安全政策所许可此用户的等
级要低。
538当前请求的认证机制需要加密
这个对于AUTH命令的响应显示当前的认证机制必须在SMTP连接被加密的情况下才
可以使用。
454临时认证失败
这个对于AUTH命令的响应显示因为临时服务器出错而导致认证失败
530需要认证
这个响应可以被任何命令返回（除了AUTH,EHLO,HELO,NOOP,RSET,或QUIT）。
它表明服务器安全策略要求认证以执行客户端的请求动作。
7.正式的语法
下面的语法定义使用了扩展的Backus-NaurForm(BNF)符号，它的具体说明在[abfn]。
除了有名的另外的方式，所有的字母表字符都是大小写不敏感的。这里使用大写或小
写字符来定义要害字符串只是为了编辑上的清楚。具体实现必须把这些字符串做为大小
写不敏感的方式来接受。
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.安全上的考虑
这里探讨有关安全的主题。
假如客户端使用这种扩展来得到一个通过一个不安全的网络到达与之合作的服务器
的加密信道，同时连接没有被交互认证和加密，它需要被配置为从没有向这个服务器发送邮
件。否则一个攻击者可以通过截获SMTP连接并假装服务器不能支持认证扩展或让所有
AUTH命令失败的方式偷走用户的邮件。
在SASL协商发生之前，任何协议交互数据都是明文而且可以被一个主动攻击者更改，
因此，客户端和服务器端都应该抛弃在SASL协商开始前的获得的信息。
这种机制不保护tcp端口，所以主动进攻者可以把一个转发连接重定向到委托端口。
AUTH=<>参数防止这种导致转发没有认证消息以恢复转发客户端的认证的攻击。
一个消息托付客户端可以要求用户不管是否被告之一个适当的SASL机制都必须认证。
因此，对一个委托服务器来说，去建议一个SASL机制使不合适的，使用这种机制通过匿名
委托给客户端不会带来任何的益处。
这种扩展不是为了取代类似s/mime或pgp的端到端的消息签名和加密系统。它和端到
端系统要解决的问题不同。有以下主要的区别：
(1)它一般只在被信任的环境中有效。
(2)它保护整个消息的报头部分，而不是邮件消息的主体部分。
(3)它对消息委托进行认证，而不是对消息内容的作者的认证。
(4)它可以给发送者一定的保证：在发送者交互认证并协商了一个合适的安全层的情
况下，这个消息确信被传递到了下一跳。
其他有关安全问题的事项在SASL规范中有论述。

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.