外文翻譯---簡(jiǎn)單郵件傳輸協(xié)議服務(wù)擴(kuò)展的認(rèn)證機(jī)制

1、<p><b>　　外文資料原文</b></p><p>　　SMTP Service Extension for Authentication</p><p><b>　　RFC 2554</b></p><p>　　This document specifies an Internet standards t

2、rack protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardizat

3、ion state and status of this protocol. Distribution of this memo is unlimited.</p><p>　　There are usually two operating modes: SMTP to send and receive SMTP. Specific way: to send SMTP mail in the received u

4、ser request to determine whether this e-mail local mail, if sent to the user's mailbox direct investment, or to check the remote mail server dns MX record, and the establishment of the remote received a two-way betwe

5、en the SMTP transmission channel, then by the sending SMTP command issued by the receiving SMTP to receive, and answer the counter-side delivery. Once the transmissi</p><p>　　SMTP commands define the mail tr

6、ansfer or by user-defined system functions. Its command is <CRLF> End of the string. In the case with parameters, the command itself is <SP> and the parameters separately, if not directly, and with parameters

7、 <CRLF> Connection. Mailbox syntax and receiving sites must be consistent with the form. SMTP commands and responses are discussed below. Send e-mail operations involving different data objects, their mutual connec

8、tion by different parameters. Reply Path param</p><p>　　An important feature of SMTP is its ability to transmit messages in the Relay, Transfer Service provides inter-process communication (IPCE), and this e

9、nvironment may include a network, several networks or a network subnet. Understand that the transmission system (or IPCE) is not a one to one very important. Process and other processes may be directly through the commun

10、ications of known IPCE. Mail is an application or inter-process communication. Mail can be connected in different IPCE the proces</p><p>　　Known as the Simple Mail Transfer Protocol SMTP (Simple Mail Transfe

11、r Protocol), aim to provide efficient and reliable message transfer. An important feature of SMTP is its ability to transmit messages in the Relay, that the message can be different relay hosts on the network transmissio

12、n. Work in two situations: First, e-mail transmission from the client to the server; second is from one server to another server. SMTP is a request / response protocol, it listen port 25, for receiving the user's<

13、/p><p>　　Copyright Notice</p><p>　　Copyright (C) the Internet Society (1999). All Rights Reserved.</p><p>　　1. Introduction</p><p>　　This document defines an SMTP service

14、extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server; perform an authentication protocol exchange, and optionally negotiate security layer for subsequent protocol interactions.

15、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:" and "S:" indicate

16、 lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined i

17、n "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 SMTP service extension is "A

18、uthentication"</p><p>　　(2) The EHLO keyword value associated with this extension is "AUTH"</p><p>　　(3) The AUTH EHLO keyword contains as a parameter a space separated list of th

19、e 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" is added to the MAIL FROM com

20、mand, 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><p>　　4. The AUTH comman

21、d AUTH mechanism [initial-response]</p><p>　　Arguments:</p><p>　　A string identifies a SASL authentication mechanism. An optional base64-encoded response</p><p>　　Restrictions:</

22、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 reject any further AUTH commands with

23、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 the server. If the server suppor

24、ts the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the user. Optionally, it also negotiates a security layer for subsequent protocol interactions. If t

25、he 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 series of server challenges and clien

26、t 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. The client answer consists of a

27、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 MUST reject th</p><p&

28、gt;　　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.</p><p>　　When the

29、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 sent in response to the empty cha

30、llenge. 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 to the AUTH command with a mecha

31、nism 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 server rejects the authentication

32、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 authentication exchange, the SMTP s

33、erver 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 negotiated through the SASL authenticati

34、on 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 layer's taking effect, the SMTP

35、 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 argument to the EHLO command, wh

36、i</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 AUTH command fails, the client may t

37、ry 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 AUTH command.</p><p>　

38、　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 mechanisms they support, independent of

39、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 smtp.example.com ESMTP server ready

40、</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</p><p>　　S: 504 unreco

41、gnized authentication types.</p><p>　　C: AUTH CRAM-MD5</p><p>　　S: 235 Authentication successful.</p><p>　　5. The AUTH parameter to the MAIL FROM command</p><p>　　AUTH=

42、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 "<>", indicating suc

43、h an identity is unknown or insufficiently authenticated.</p><p>　　Discussion:</p><p>　　The optional AUTH parameter to the MAIL FROM command allows cooperating agents in a trusted environment to

44、 communicate the authentication of 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

45、 supplied addr-spec, and then the server 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 AUT

46、H=<> indicates that the original 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 M

47、AIL FROM is not supplied, the client has 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 w

48、hen relaying the message to any server 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, t

49、hen the server MUST behave as if the AUTH=<> 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, e

50、ither explicitly or due to the requirement 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

51、.</p><p>　　A server MAY treat 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

52、subscribers.</p><p>　　It 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 s

53、yntactically valid AUTH parameters to 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&

54、gt;<p>　　C: MAIL FROM :< e=mc2@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 ma

55、y be used to indicate various conditions 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

56、selected authentication mechanism. This typically done by authenticating that once using the PLAIN authentication mechanism.534 Authentication mechanisms is too weak.</p><p>　　This response to the AUTH comma

57、nd indicates that the selected authentication mechanism is weaker than server policy permits for that user.</p><p>　　538 Encryption required for requested authentication mechanism</p><p>　　This

58、response to the AUTH command indicates that the selected authentication mechanism may only be used when the underlying SMTP connection is encrypted.</p><p>　　454 Temporary authentication failures</p>

59、<p>　　This response 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 return

60、ed by any command other than 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><

61、p>　　The following syntax 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 u

62、se of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.</p><p>　　8. Security Considerations</p&

63、gt;<p>　　Security issues are discussed throughout this memo. If a client uses this extension to get an encrypted tunnel through an insecure network to a cooperating server, it needs to be configured to never send

64、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 connection and either pretending the server does not sup

65、port the Authentication extension or causing all AUTH commands to fail.</p><p>　　Before the SASL negotiation has begun, any protocol interactions are performed in the clear and may be modified by an active a

66、ttacker. 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 results in a security layer.</p><p>　　

67、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 prevents such an attack from causing a relayed mess

68、age without an envelope authentication to pick up the authentication of the relay client.</p><p>　　A message submission client may require the user to authenticate whenever a suitable SASL mechanism is adver

69、tised. 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 anonymous submission.</p><p>　　This exte

70、nsion 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 problem than end-to-end systems; it has the followin

71、g 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, not just the message's body.</p><p&

72、gt;　　(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 delivered to the next hop in the case where the send

73、er mutually authenticates with the next hop and negotiates an appropriate security layer.</p><p>　　Additional security considerations are mentioned in the SASL specification [SASL].</p><p>　　E-M

74、ail plays a very important role in modern times. More and more people are using it, and the number of it will larger and larger. Though there are a lot of software for sending and receiving letters such as FoxMail which

75、are also multifunctional, it is difficult and complicated to the Most of people who are curbstone. For this reason, we do this software with the rock-bottom protocol of SMTP and Pop. The full name of SMTP is Simple Mail

76、Transfer Protocol. It is used to sending letters. The ful</p><p>　　The rapid development of the Internet has to become the world's most extensive coverage, the largest and most abundant resources of the

77、information network. In the age of the Internet, people share information in the full enjoyment by the convenience of also suffering from "information hungry", "spam" and other problems. How to help u

78、sers from the Internet access useful information and avoid unhealthy information network pollution has now become an urgent need for research to solve a problem.</p><p>　　Network Information filtering is bas

79、ed on certain standards and the use of certain tools from the dynamic network information flow, select relevant information or omissions of information not related to a series of process. Information filtering technology

80、 applications help to reduce pressure on the user's knowledge; contribute to the personality of the network information services; help to improve the efficiency of access to information; can reduce unnecessary transm

81、ission of information so tha</p><p>　　Information filtering processed generally, the information filtering technology use into the network security field. Use of TCP / IP protocol to the basic principles of

82、the agreement SMTP, POP3 protocol and HTTP protocol packets, the e-mail data and WEB access to data tracking. Finally, from the perspective system performance analysis and design of a variety of information filtering rul

83、es, enabling the system to adapt to different applications to meet different needs.</p><p><b>　　譯文</b></p><p>　　簡(jiǎn)單郵件傳輸協(xié)議服務(wù)擴(kuò)展的認(rèn)證機(jī)制</p><p><b>　　RFC 2554</b><

84、;/p><p>　　這個(gè)文檔詳細(xì)說(shuō)明了因特網(wǎng)團(tuán)體的一個(gè)標(biāo)準(zhǔn)的協(xié)議的發(fā)展，以及對(duì)其改進(jìn)和建議提出了要求。說(shuō)到這，為了標(biāo)準(zhǔn)化這個(gè)協(xié)議的狀態(tài)和地位，就必須提及目前最新的“Internet 官方協(xié)議的標(biāo)準(zhǔn)”(STD1)。發(fā)送這個(gè)文檔是不受限制的。</p><p>　　簡(jiǎn)單郵件傳輸協(xié)議通常有兩種工作模式：發(fā)送簡(jiǎn)單郵件傳輸協(xié)議和接收簡(jiǎn)單郵件傳輸協(xié)議。具體工作方式為：發(fā)送簡(jiǎn)單郵件傳輸協(xié)議在接到用戶(hù)的郵件請(qǐng)求

85、后，判斷此郵件是否為本地郵件，若是直接投送到用戶(hù)的郵箱，則向 DNS查詢(xún)遠(yuǎn)端郵件服務(wù)器的MX紀(jì)錄，并建立與遠(yuǎn)端接收簡(jiǎn)單郵件傳輸協(xié)議之間的一個(gè)雙向傳送通道，此后簡(jiǎn)單郵件傳輸協(xié)議命令由發(fā)送簡(jiǎn)單郵件傳輸協(xié)議發(fā)出，由接收簡(jiǎn)單郵件傳輸協(xié)議接收，而應(yīng)答則反方面?zhèn)魉?。一旦傳送通道建立，?jiǎn)單郵件傳輸協(xié)議發(fā)送者發(fā)送MAIL命令指明郵件發(fā)送者。如果簡(jiǎn)單郵件傳輸協(xié)議接收者可以接收郵件則返回OK應(yīng)答。簡(jiǎn)單郵件傳輸協(xié)議發(fā)送者再發(fā)出接收命令確認(rèn)郵件是否接收到。如果

86、簡(jiǎn)單郵件傳輸協(xié)議接收者接收，則返回OK應(yīng)答；如果不能接收到，則發(fā)出拒絕接收應(yīng)答（但不中止整個(gè)郵件操作），雙方將如此重復(fù)多次。當(dāng)接收者收到全部郵件后會(huì)接收到特別的序列，如果接收者成功處理了郵件，則返回“OK”應(yīng)答。</p><p>　　簡(jiǎn)單郵件傳輸協(xié)議命令定義了郵件傳輸或由用戶(hù)定義的系統(tǒng)功能。它的命令是由<CRLF>結(jié)束的字符串。而在帶有參數(shù)的情況下，命令本身由<SP>和參數(shù)分開(kāi)，如果未帶參

87、數(shù)可以直接和<CRLF>連接。郵箱的語(yǔ)法格式必須和接收站點(diǎn)的格式一致。下面討論簡(jiǎn)單郵件傳輸協(xié)議命令和應(yīng)答。</p><p>　　發(fā)送郵件操作涉及到不同的數(shù)據(jù)對(duì)象，它們由不同的參數(shù)相互連接。回復(fù)路徑就是MAIL命令的參數(shù)，而轉(zhuǎn)發(fā)路徑則是接收命令的參數(shù)，郵件日期是DATA命令的參數(shù)。這些參數(shù)或者數(shù)據(jù)對(duì)象必須跟在命令后。這種模式也就要求有不同的緩沖區(qū)來(lái)存儲(chǔ)這些對(duì)象，也就是說(shuō)，有一個(gè)回復(fù)路徑緩沖區(qū)，一個(gè)轉(zhuǎn)發(fā)路

88、徑緩沖區(qū)，一個(gè)郵件內(nèi)容緩沖區(qū)。特定的命令產(chǎn)生自己的緩沖區(qū)，或使一個(gè)或多個(gè)緩沖的內(nèi)容被清除。</p><p>　　簡(jiǎn)單郵件傳輸協(xié)議的一個(gè)重要特點(diǎn)是它能夠在傳送中接力傳送郵件，傳送服務(wù)提供了進(jìn)程間通信環(huán)境（IPCE），此環(huán)境可以包括一個(gè)網(wǎng)絡(luò)，幾個(gè)網(wǎng)絡(luò)或一個(gè)網(wǎng)絡(luò)的子網(wǎng)。理解到傳送系統(tǒng)（或IPCE）不是一對(duì)一的是很重要的。進(jìn)程可能直接和其它進(jìn)程通過(guò)已知的IPCE通信。郵件是一個(gè)應(yīng)用程序或進(jìn)程間通信。郵件可以通過(guò)連接在不同

89、IPCE上的進(jìn)程跨越網(wǎng)絡(luò)進(jìn)行郵件傳送。更特別的是，郵件可以通過(guò)不同網(wǎng)絡(luò)上的主機(jī)接力式傳送。</p><p>　　簡(jiǎn)單郵件傳輸協(xié)議稱(chēng)為簡(jiǎn)單Mail傳輸協(xié)議（Simple Mail Transfer Protocol），目標(biāo)是向用戶(hù)提供高效、可靠的郵件傳輸。簡(jiǎn)單郵件傳輸協(xié)議的一個(gè)重要特點(diǎn)是它能夠在傳送中接力傳送郵件，即郵件可以通過(guò)不同網(wǎng)絡(luò)上的主機(jī)接力式傳送。工作在兩種情況下：一是電子郵件從客戶(hù)機(jī)傳輸?shù)椒?wù)器；二是從某

90、一個(gè)服務(wù)器傳輸?shù)搅硪粋€(gè)服務(wù)器。簡(jiǎn)單郵件傳輸協(xié)議是個(gè)請(qǐng)求/響應(yīng)協(xié)議，它監(jiān)聽(tīng)25號(hào)端口，用于接收用戶(hù)的Mail請(qǐng)求，并與遠(yuǎn)端Mail服務(wù)器建立簡(jiǎn)單郵件傳輸協(xié)議連接。</p><p><b>　　版權(quán)須知</b></p><p>　　版權(quán)所有（1999年）Internet 團(tuán)體，所有權(quán)利將得到保留。</p><p><b>　　1、簡(jiǎn)介&l

91、t;/b></p><p>　　這個(gè)文檔定義了簡(jiǎn)單郵件傳輸協(xié)議服務(wù)的擴(kuò)展（E簡(jiǎn)單郵件傳輸協(xié)議）并且說(shuō)明了一個(gè)簡(jiǎn)單郵件傳輸協(xié)議客戶(hù)端可以為服務(wù)器指定一種用來(lái)執(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>　　在以下的這些

92、例子中，C和S分別表示客戶(hù)端和服務(wù)器。</p><p>　　諸如MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"這些關(guān)鍵性的單詞被可以看作和“用在RFC文檔中用來(lái)標(biāo)示必須的級(jí)別的關(guān)鍵字” [KEYWORDS]相同的解釋。</p><p><

93、b>　　3、認(rèn)證服務(wù)的擴(kuò)展</b></p><p>　　(1)簡(jiǎn)單郵件傳輸協(xié)議服務(wù)擴(kuò)展的名稱(chēng)是 "被動(dòng)認(rèn)證"</p><p>　　(2)聯(lián)合這個(gè)擴(kuò)展的EHLO關(guān)鍵字的值是“認(rèn)證”</p><p>　　(3)認(rèn)證 EHLO關(guān)鍵字 是一個(gè)有空格間隔的被SASL機(jī)制支持的名字列表的參數(shù)</p><p>　　(4

94、)一個(gè)新的簡(jiǎn)單郵件傳輸協(xié)議動(dòng)詞“認(rèn)證”定義完成</p><p>　　(5)用在關(guān)鍵字“認(rèn)證”的一個(gè)可選的參數(shù)被附加到郵件來(lái)源命令里，用來(lái)指定郵件來(lái)源命令一行的最大長(zhǎng)度不能超過(guò)500個(gè)字符</p><p>　　(6) 此擴(kuò)展和委托協(xié)議兼容</p><p><b>　　4、認(rèn)證命令</b></p><p>　　認(rèn)證機(jī)制[初始

95、化響應(yīng)]</p><p><b>　　觀點(diǎn)：</b></p><p>　　用來(lái)標(biāo)識(shí)SASL認(rèn)證機(jī)制的一個(gè)字符串</p><p>　　可選的Base64編碼的一個(gè)響應(yīng)</p><p><b>　　約束：</b></p><p>　　再成功發(fā)出了一個(gè)認(rèn)證命令之后，在同一時(shí)間段里不

96、能再執(zhí)行其他的認(rèn)證命令。在成功執(zhí)行了一個(gè)認(rèn)證命令之后，服務(wù)器必須拒絕后來(lái)的認(rèn)證命令并且返回一個(gè)503響應(yīng)碼。</p><p>　　在處理一個(gè)郵件事務(wù)期間，服務(wù)器不會(huì)再接受認(rèn)證命令。</p><p><b>　　討論：</b></p><p>　　認(rèn)證命令顯示了一種和郵件服務(wù)器間的安全認(rèn)證機(jī)制 。如果郵件服務(wù)器支持這種認(rèn)證機(jī)制，它就會(huì)執(zhí)行一個(gè)認(rèn)證

97、協(xié)議來(lái)認(rèn)證并識(shí)別郵件用戶(hù)。作為可選的情況，他也會(huì)忽略這以后協(xié)議交互的一個(gè)安全層。如果服務(wù)器并不支持所需要的認(rèn)證協(xié)議，就會(huì)用504的回答來(lái)拒絕這個(gè)認(rèn)證命令。</p><p>　　這種認(rèn)證機(jī)制的交互，由一系列的服務(wù)器的響應(yīng)和對(duì)認(rèn)證機(jī)制來(lái)說(shuō)的一些特殊的回答來(lái)組成。服務(wù)器的正確響應(yīng)，不同于其他的響應(yīng)的是針對(duì)文本部分采用Base64編碼以334作為回應(yīng)的?？蛻?hù)端的回應(yīng)是一個(gè)包含Base64編碼的字符串的隊(duì)列。如果客戶(hù)端想取

98、消與服務(wù)器的認(rèn)證交互，就執(zhí)行一個(gè)單個(gè)的“*”。如果服務(wù)器接到這樣一個(gè)回應(yīng)，就通過(guò)發(fā)送一個(gè)501的響應(yīng)來(lái)拒絕執(zhí)行認(rèn)證命令。</p><p>　　對(duì)認(rèn)證命令來(lái)說(shuō)，可選的初始化響應(yīng)建議是用來(lái)在使用認(rèn)證機(jī)制時(shí)保持一個(gè)往返的回程,認(rèn)證機(jī)制的定義中此建議不發(fā)送任何數(shù)據(jù)。當(dāng)初始化響應(yīng)部分用在這種機(jī)制時(shí)，開(kāi)始的空的發(fā)起命令不被送到客戶(hù)端，并且服務(wù)器端使用的數(shù)據(jù)也好像是發(fā)送來(lái)響應(yīng)一個(gè)空的命令。它發(fā)送一個(gè)零長(zhǎng)度的初始化回答作為一個(gè)&

99、quot;="符號(hào)。如果客戶(hù)端在認(rèn)證機(jī)制的認(rèn)證命令響應(yīng)中使用初始化建議，客戶(hù)端就在初始化命令中發(fā)送響應(yīng)的數(shù)據(jù)，服務(wù)器端用535回答來(lái)拒絕認(rèn)證命令。</p><p>　　如果服務(wù)器不能對(duì)發(fā)送來(lái)的命令采用Base64解碼的話(huà)，將拒絕執(zhí)行認(rèn)證命令，并返回501響應(yīng)。如果服務(wù)器拒絕認(rèn)證的數(shù)據(jù)，服務(wù)器應(yīng)該拒絕執(zhí)行并返回一個(gè)535響應(yīng)碼除非有更詳細(xì)的錯(cuò)誤代碼，例如在Section 6列出來(lái)的那個(gè)。如果客戶(hù)端和服務(wù)器

100、進(jìn)行了正確的交互的操作的話(huà)，簡(jiǎn)單郵件傳輸協(xié)議服務(wù)器將發(fā)出一個(gè)235響應(yīng)碼。</p><p>　　詳細(xì)說(shuō)明這個(gè)SASL側(cè)面的服務(wù)器的名稱(chēng)是“簡(jiǎn)單郵件傳輸協(xié)議”。</p><p>　　如果SASL認(rèn)證交互穿越了一個(gè)安全層，將會(huì)通過(guò)一個(gè)有用來(lái)中止認(rèn)證交互的CRLF來(lái)產(chǎn)生效果，而服務(wù)器也通過(guò)一個(gè)CRLF做出正確的響應(yīng)。在服務(wù)器安全層級(jí)生效之前，簡(jiǎn)單郵件傳輸協(xié)議被重置到初始狀態(tài)（簡(jiǎn)單郵件傳輸協(xié)議中的

101、狀態(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本身而獲得的簡(jiǎn)單郵件傳輸協(xié)議服務(wù)擴(kuò)展的隊(duì)列?？蛻?hù)端的SHOULD在SASL商議成功之后，發(fā)出一個(gè)EHLO命令作為第一個(gè)命令，這些將使得安全層級(jí)得到授權(quán)。</p><p>　　服務(wù)器不一

102、定要求支持任何的認(rèn)證機(jī)制，而認(rèn)證機(jī)制也不一定要支持所有的安全層。如果一個(gè)認(rèn)證命令失敗了，客戶(hù)端將試圖執(zhí)行另一個(gè)認(rèn)證機(jī)制的認(rèn)證命令。</p><p>　　一個(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)度的限制。</p><p><b>

103、;　　例如：</b></p><p>　　服務(wù)器：220簡(jiǎn)單郵件傳輸協(xié)議服務(wù)器準(zhǔn)就緒</p><p>　　客戶(hù)端：響應(yīng)以上命令</p><p>　　服務(wù)器：250-簡(jiǎn)單郵件傳輸協(xié)議</p><p>　　服務(wù)器：250認(rèn)證CRAM-MD5 DIGEST-MD5</p><p>　　客戶(hù)端：認(rèn)證FOOBAR&l