外文翻譯--smtp服務(wù)擴(kuò)展的認(rèn)證機(jī)制

1、<p><b>　　外文文獻(xiàn)原文</b></p><p>　　SMTP Service Extension for Authentication</p><p>　　This document specifies an Internet standards track protocol for the Internet community, and requ

2、ests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distributio

3、n of this memo is unlimited.</p><p>　　Copyright Notice</p><p>　　Copyright (C) The Internet Society (1999). All Rights Reserved.</p><p>　　1. Introduction</p><p>　　This d

4、ocument defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server,perform an authentication protocol exchange, and optionally negotiatea security layer for su

5、bsequent protocol interactions. This extension is a profile of the Simple Authentication and Security Layer [SASL].</p><p>　　2. Conventions Used in this Document</p><p>　　In examples, "C:&q

6、uot; and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document ar

7、e to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].</p><p>　　3. The Authentication service extension</p><p>　　(1) the name of the S

8、MTP service extension is "Authentication"</p><p>　　(2) the EHLO keyword value associated with this extension is "AUTH"</p><p>　　(3) The AUTH EHLO keyword contains as a parame

9、ter a space separated list of the names of supported SASL mechanisms.</p><p>　　(4) a new SMTP verb "AUTH" is defined</p><p>　　(5) an optional parameter using the keyword "AUTH&quo

10、t; 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 appropriate for the submission protocol [SUBMIT].</p>

11、;<p>　　4. The AUTH command AUTH mechanism [initial-response]</p><p>　　Arguments:</p><p>　　a string identifying a SASL authentication mechanism. an optional base64-encoded response</p&g

12、t;<p>　　Restrictions:</p><p>　　After an AUTH command has successfully completed, no more AUTH commands may be issued in the same session. After a successful AUTH command completes, a server MUST rejec

13、t any further AUTH commands with a 503 reply. The AUTH command is not permitted during a mail transaction.</p><p>　　Discussion:</p><p>　　The AUTH command indicates an authentication mechanism to

14、 the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the user. Optionally, it also negotiates a security layer for subse

15、quent protocol interactions. If the requested authentication mechanism is not supported, the server rejects the AUTH command with a 504 reply.</p><p>　　The authentication protocol exchange consists of a seri

16、es 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 with the text part containing a BASE64 encoded string.

17、 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 "*". If the server receives such an answer, it

18、 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 that are defined to send no data in the initial challenge

19、.</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 the data in the initial-response argument as if it were

20、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 ("="). If the client uses an initial-response argument

21、 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, it rejects the AUTH command with a 501 reply. If the s

22、erver 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 appropriate. Should the client successfully complete the au

23、thentication exchange, the SMTP server issues a 235 reply.</p><p>　　The service name specified by this protocol's profile of SASL is "smtp".</p><p>　　If a security layer is negotia

24、ted through the SASL authentication exchange, it takes effect immediately following the CRLF that concludes the authentication exchange for the client, and the CRLF of the success reply for the server. Upon a security la

25、yer'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 discard any knowledge obtained from the client, such as the

26、 argument to the EHLO command, whi</p><p>　　The server is not required to support any particular authentication mechanism, nor are authentication mechanisms required to support any security layers. If an AUT

27、H command fails, the client may try another authentication mechanism by issuing another AUTH command.</p><p>　　If an AUTH command fails, the server MUST behave the same as if the client had not issued the AU

28、TH 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 as long as are generated by the authentication mechani

29、sms they support, independent of any line length limitations the client or server may have in other parts of its protocol implementation.</p><p><b>　　Examples:</b></p><p>　　S: 220 sm

30、tp.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-MD5 DIGEST-MD5</p><p>　　C: AUTH FOOBAR<

31、/p><p>　　S: 504 Unrecognized authentication type.</p><p>　　C: AUTH CRAM-MD5</p><p><b>　　S: 334</b></p><p>　　PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z

32、0LmNvbT4=</p><p>　　C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==</p><p>　　S: 235 Authentication successful.</p><p>　　5. The AUTH parameter to the MAIL FROM command</p&g

33、t;<p>　　AUTH=addr-spec</p><p>　　Arguments:</p><p>　　An addr-spec containing the identity which submitted the message to the delivery system, or the two character sequence "<>&q

34、uot; indicating such an identity is unknown or insufficiently authenticated. To comply with the restrictions imposed on ESMTP parameters, the addr-spec is encoded inside an xtext. The syntax of an xtext is described in s

35、ection 5 of [ESMTP-DSN].</p><p>　　Discussion:</p><p>　　The optional AUTH parameter to the MAIL FROM command allows cooperating agents in a trusted environment to communicate the authentication o

36、f individual messages.</p><p>　　If the server trusts the authenticated identity of the client to</p><p>　　assert that the message was originally submitted by the supplied addr-spec, then the ser

37、ver 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 FROM parameter of AUTH=<> indicates that the origina

38、l 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 parameter to the MAIL FROM is not supplied, the client h

39、as 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 AUTH parameter when relaying the message to any server

40、 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 authenticated, then the server MUST behave as if the A

41、UTH=<> parameter was supplied. The server MAY, however, write the value of the AUTH parameter to a log file.</p><p>　　If an AUTH=<> parameter was supplied, either explicitly or due to the require

42、ment 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 the AUTH extension.</p><p>　　A server MAY t

43、reat 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 message to list subscribers.</p><p>　　It

44、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 parse and discard syntactically valid AUTH parameters to

45、the MAIL FROM command and supply AUTH=<> parameters to any servers to which it authenticates using the AUTH extension.</p><p><b>　　Examples:</b></p><p>　　C: MAIL FROM:<e=mc2

46、@example.com> AUTH=e+3Dmc2@example.com</p><p><b>　　S: 250 OK</b></p><p>　　6. Error Codes</p><p>　　The following error codes may be used to indicate various conditions

47、 as described.</p><p>　　432 A password transition is needed</p><p>　　This response to the AUTH command indicates that the user needs to transition to the selected authentication mechanism. This

48、typically done by authenticating once using the PLAIN authentication mechanism.</p><p>　　534 Authentication mechanism is too weak</p><p>　　This response to the AUTH command indicates that the se

49、lected authentication mechanism is weaker than server policy permits for that user.</p><p>　　538 Encryption required for requested authentication mechanism</p><p>　　This response to the AUTH com

50、mand indicates that the selected authentication mechanism may only be used when the underlying SMTP connection is encrypted.</p><p>　　454 Temporary authentication failure</p><p>　　This response

51、to the AUTH command indicates that the authentication failed due to a temporary server failure.</p><p>　　530 Authentication required</p><p>　　This response may be returned by any command other t

52、han AUTH, EHLO, HELO, NOOP, RSET, or QUIT. It indicates that server policy requires authentication in order to perform the requested action.</p><p>　　7. Formal Syntax</p><p>　　The following synt

53、ax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [ABNF].</p><p>　　Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case

54、 characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.</p><p>　　UPALPHA = %x41-5A ;; Uppercase: A-Z</p><p>　　

55、LOALPHA = %x61-7A ;; Lowercase: a-z</p><p>　　ALPHA = UPALPHA / LOALPHA ;; case insensitive</p><p>　　DIGIT = %x30-39 ;; Digits 0-9</p><p>　　HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal

56、digit (uppercase)</p><p>　　hexchar = "+" HEXDIGIT HEXDIGIT</p><p>　　xchar = %x21-2A / %x2C-3C / %x3E-7E;; US-ASCII except for "+", "=", SPACE and CTL</p><

57、;p>　　xtext = *(xchar / hexchar)</p><p>　　AUTH_CHAR = ALPHA / DIGIT / "-" / "_"</p><p>　　auth_type = 1*20AUTH_CHAR</p><p>　　auth_command = "AUTH" SPA

58、CE auth_type [SPACE (base64 / "=")]*(CRLF [base64]) CRLF</p><p>　　auth_param = "AUTH=" xtext;; The decoded form of the xtext MUST be either;; an addr-spec or the two characters "<

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

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

61、urn</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

62、SP, space</p><p>　　8. References</p><p>　　[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC2234, November 1997.</p><p>　　[CRAM-MD5] K

63、lensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.</p><p>　　[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and

64、D. Crocker, "SMTP Service Extensions", RFC1869, November 1995.</p><p>　　[ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC1891, January 1996.</p>

65、<p>　　[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997</p><p>　　[SASL] Myers, J., "Simple Authentication and Security Layer

66、 (SASL)", RFC2222, October 1997.</p><p>　　[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.</p><p>　　[RFC821] Postel, J., "Simple Mail Trans

67、fer Protocol", STD 10, RFC 821, August 1982.</p><p>　　[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC822, August 1982.</p><p>　　9. Secu

68、rity Considerations</p><p>　　Security issues are discussed throughout this memo.</p><p>　　If a client uses this extension to get an encrypted tunnel through an insecure network to a cooperating

69、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 steal the client's mail by hijacking the SMTP connecti

70、on and either pretending the server does not support the Authentication extension or causing all AUTH commands to fail.</p><p>　　Before the SASL negotiation has begun, any protocol interactions are performed

71、 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 negotiation upon completion of a SASL negotiation which res

72、ults in a security layer.</p><p>　　This mechanism does not protect the TCP port, so an active attacker may redirect a relay connection attempt to the submission port [SUBMIT]. The AUTH=<> parameter pre

73、vents such an attack from causing an relayed message without an envelope authentication to pick up the authentication of the relay client.</p><p>　　A message submission client may require the user to authent

74、icate whenever a suitable SASL mechanism is advertised. Therefore, it may not be desirable for a submission server [SUBMIT] to advertise a SASL mechanism when use of that mechanism grants the client no benefits over anon

75、ymous submission.</p><p>　　This extension is not intended to replace or be used instead of end- to-end message signature and encryption systems such as S/MIME or PGP. This extension addresses a different pro

76、blem than end-to-end systems; it has the following key differences:</p><p>　　(1) it is generally useful only within a trusted enclave</p><p>　　(2) it protects the entire envelope of a message, n

77、ot just the message's body.</p><p>　　(3) it authenticates the message submission, not authorship of the message content</p><p>　　(4) it can give the sender some assurance the message was del

78、ivered to the next hop in the case where the sender mutually authenticates with the next hop and negotiates an appropriate security layer.</p><p>　　Additional security considerations are mentioned in the SAS

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

80、)。發(fā)送這個(gè)文檔是不受限制的。</p><p><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）并且說明了一個(gè)SMT

81、P客戶端可以為服務(wù)器指定一種用來執(zhí)行與認(rèn)證協(xié)議的交換，并且隨意地穿越并發(fā)的協(xié)議之間交互的安全層的認(rèn)證機(jī)制。這個(gè)擴(kuò)展是“簡(jiǎn)單認(rèn)證和安全層”[SASL]的一個(gè)側(cè)面。</p><p>　　2 這個(gè)文檔用到的協(xié)定</p><p>　　在以下的這些例子中，C和S分別表示客戶端和服務(wù)器。</p><p>　　諸如MUST", "MUST NOT"

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

83、><p>　　聯(lián)合這個(gè)擴(kuò)展的EHLO關(guān)鍵字的值是“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命令里，用來指定MA

84、IL FROM命令一行的最大長(zhǎng)度不能超過500個(gè)字符。</p><p>　　(6) 此擴(kuò)展和委托協(xié)議兼容。</p><p><b>　　4 AUTH命令</b></p><p>　　AUTH機(jī)制[初始化響應(yīng)]</p><p><b>　　觀點(diǎn)：</b></p><p>　　

85、用來標(biāo)識(shí)SASL認(rèn)證機(jī)制的一個(gè)字符串</p><p>　　可選的Base64編碼的一個(gè)響應(yīng)</p><p><b>　　約束：</b></p><p>　　再成功發(fā)出了一個(gè)AUTH命令之后，在同一時(shí)間段里不能再執(zhí)行其他的AUTH命令。在成功執(zhí)行了一個(gè)AUTH命令之后，服務(wù)器必須拒絕后來的AUTH命令并且返回一個(gè)503響應(yīng)碼。</p>

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

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

88、UTH命令。</p><p>　　對(duì)AUTH命令來說，可選的初始化響應(yīng)建議是用來在使用認(rèn)證機(jī)制時(shí)保持一個(gè)往</p><p>　　返的回程,認(rèn)證機(jī)制的定義中此建議不發(fā)送任何數(shù)據(jù)。當(dāng)初始化響應(yīng)部分用在這種機(jī)制時(shí)，</p><p>　　開始的空的發(fā)起命令不被送到客戶端，并且服務(wù)器端使用的數(shù)據(jù)也好象是發(fā)送來 </p><p>　　響應(yīng)

89、一個(gè)空的命令。它發(fā)送一個(gè)零長(zhǎng)度的初始化回答作為一個(gè)"="符號(hào)。如果客戶端 </p><p>　　在認(rèn)證機(jī)制的AUTH命令響應(yīng)中使用初始化建議，客戶端就在初始化命令中發(fā)送響應(yīng)的 </p><p>　　數(shù)據(jù)，服務(wù)器端用535回答來拒絕AUTH命令。</p><p>　　如果服務(wù)器不能對(duì)發(fā)送來的命令采用Base64解碼的

90、話，將拒絕執(zhí)行Auth命令，并返回501響應(yīng)。如果服務(wù)器拒絕認(rèn)證的數(shù)據(jù)，服務(wù)器應(yīng)該拒絕執(zhí)行并返回一個(gè)535響應(yīng)碼除非有更詳細(xì)的錯(cuò)誤代碼，例如在Section 6列出來的那個(gè)。如果客戶端和服務(wù)器進(jìn)行了正確的交互的操作的話，SMTP服務(wù)器將發(fā)出一個(gè)235響應(yīng)碼。</p><p>　　詳細(xì)說明這個(gè)SASL側(cè)面的服務(wù)器的名稱是”SMTP“。</p><p>　　如果SASL認(rèn)證交互穿越了一個(gè)安全層

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

92、SHOULD在SASL商議成功之后，發(fā)出一個(gè)EHLO命令做為第一個(gè)命令，這些將使得安全層得到授權(quán)。</p><p>　　服務(wù)器不一定要求支持任何的認(rèn)證機(jī)制，而認(rèn)證機(jī)制也不一定要支持所有的安全層。如果一個(gè)AUTH命令失敗了，客戶端將試圖執(zhí)行另一個(gè)認(rèn)證機(jī)制的AUTH命令。</p><p>　　一個(gè)Base64編碼的字符串通常來說是沒有長(zhǎng)度限制的。只要由認(rèn)證機(jī)制產(chǎn)生的受客戶端和服務(wù)器支持的命令和

93、響應(yīng)，客戶端和服務(wù)器端必須支持，而不依賴于服務(wù)器或者客戶端的、可能存在于協(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

94、><p>　　C: EHLO jgm.example.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

95、authentication type.</p><p>　　C: AUTH CRAM-MD5</p><p><b>　　S: 334</b></p><p>　　PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=</p><p>　　C: ZnJl

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

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

98、選的參數(shù)的MAIL FROM 命令允許一個(gè)協(xié)同工作的代理與一單獨(dú)的消息就行通信在一個(gè)被信任的環(huán)境里。</p><p>　　如果服務(wù)器認(rèn)為最初提交消息的Addr－dec的客戶端是可信任的話，將會(huì)發(fā)出一個(gè)聲明，接著服務(wù)器應(yīng)當(dāng)提供一個(gè)相同的addr－dec給任何其他支持AUTH擴(kuò)展的用來中轉(zhuǎn)消息的服務(wù)器。</p><p>　　如果MAIL FROM命令中那個(gè)可選的AUTH命令的參數(shù)沒有得到提供的

99、話，而客戶端已經(jīng)得到認(rèn)證，那么服務(wù)器認(rèn)為消息是由客戶端提交的原始的信息，那么在中轉(zhuǎn)給其他的中繼服務(wù)器的時(shí)候，當(dāng)前服務(wù)器就會(huì)把a(bǔ)ddr－dec做為Auth命令的可選的參數(shù)提供給其它的服務(wù)器。</p><p>　　如果服務(wù)器不是充分的相信客戶端的身份或者客戶端并沒有得到認(rèn)證的話，那么服務(wù)器必須自己提供AUTH命令的那個(gè)參數(shù)一個(gè)值。并且將這個(gè)值寫入到日志文件中。</p><p>　　如果AUTH

100、命令的可選的參數(shù)已經(jīng)提供了的話，不管是明確的提出還是由于前面段落的需要，服務(wù)器應(yīng)當(dāng)提供這個(gè)參數(shù)給任何其他支持AUTH擴(kuò)展的用來中轉(zhuǎn)消息的服務(wù)器。</p><p>　　服務(wù)器將把郵件列表的擴(kuò)充視為一個(gè)新的任務(wù)，AUTH命令加入到郵件地址列表中，或者在中轉(zhuǎn)這些消息到列表簽署者的時(shí)候管理郵件列表。</p><p>　　為了一致，在一個(gè)執(zhí)行很難被編碼的時(shí)候，服務(wù)器將認(rèn)為所有的這些客戶端都是不可信任

101、的。在這種情況下，服務(wù)器能做的僅僅就是解析有效的AUTH命令的參數(shù)，并把它提供給任所有使用AUTH擴(kuò)展的認(rèn)證機(jī)制的服務(wù)器，并遺棄無效的參數(shù)。</p><p><b>　　例如：</b></p><p>　　C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com</p><p&g

102、t;<b>　　S: 250 OK</b></p><p><b>　　6 錯(cuò)誤代碼</b></p><p>　　以下的錯(cuò)誤代碼常常用來描述和標(biāo)識(shí)各種情況。</p><p>　　432 需要進(jìn)行密碼的轉(zhuǎn)換</p><p>　　這個(gè)響應(yīng)碼表示，對(duì)于服務(wù)器的認(rèn)證機(jī)制來講，用戶必須進(jìn)行一個(gè)轉(zhuǎn)換。比較

103、由代表性的就是一旦你使用了PLAIN認(rèn)證機(jī)制的話，就必須進(jìn)行轉(zhuǎn)換。</p><p>　　534 認(rèn)證機(jī)過于簡(jiǎn)單</p><p>　　這個(gè)響應(yīng)碼表示的是選擇的認(rèn)證機(jī)制相對(duì)于服務(wù)器所允許的認(rèn)證機(jī)制來說顯得太弱了。</p><p>　　538 請(qǐng)求的認(rèn)證機(jī)制需要加密</p><p>　　這個(gè)響應(yīng)碼表示的是所選的認(rèn)證機(jī)制只有在SMTP連接是需要加

104、密的情況下才用的著</p><p>　　454 暫時(shí)的認(rèn)證失敗</p><p>　　這個(gè)響應(yīng)碼表示的是認(rèn)證失敗的原因是由于服務(wù)器暫時(shí)出現(xiàn)問題</p><p>　　530 認(rèn)證是必須的</p><p>　　除了AUTH，EHLO，HELO，NOOP，RESET或者QUIT這幾個(gè)命令之外的任何一個(gè)命令，都將返回這個(gè)響應(yīng)碼。這表示服務(wù)器需要為了

105、執(zhí)行被請(qǐng)求的操作，需要一個(gè)認(rèn)證。</p><p><b>　　7 正規(guī)的語(yǔ)法</b></p><p>　　以下的用在擴(kuò)展的BNF符號(hào)和用在ABNF中的語(yǔ)法的規(guī)格是一樣的。</p><p>　　除了那些被標(biāo)注的以外，所有的按字母順序排列的特征都是適合于固定場(chǎng)合的。排在上面的或者下面的被用來定義為有象征意義的字符串的用處僅僅是為了編輯時(shí)的便利以及

106、清晰。執(zhí)行這些必須在以固定的格式在一定的場(chǎng)合來接受這些字符串。</p><p>　　UPALPHA = %x41-5A ;; Uppercase: A-Z</p><p>　　LOALPHA = %x61-7A ;; Lowercase: a-z</p><p>　　ALPHA = UPALPHA / LOALPHA ;; case insensitive</

107、p><p>　　DIGIT = %x30-39 ;; Digits 0-9</p><p>　　HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)</p><p>　　hexchar = "+" HEXDIGIT HEXDIGIT</p><p>　　xcha

108、r = %x21-2A / %x2C-3C / %x3E-7E</p><p>　　;; US-ASCII except for "+", "=", SPACE and CTL</p><p>　　xtext = *(xchar / hexchar)</p><p>　　AUTH_CHAR = ALPHA / DIGIT /