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

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>　　簡單郵件傳輸協(xié)議服務(wù)擴展的認(rèn)證機制</p><p><b>　　RFC 2554</b><

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

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

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

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

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

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

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

91、t;/b></p><p>　　這個文檔定義了簡單郵件傳輸協(xié)議服務(wù)的擴展（E簡單郵件傳輸協(xié)議）并且說明了一個簡單郵件傳輸協(xié)議客戶端可以為服務(wù)器指定一種用來執(zhí)行與認(rèn)證協(xié)議的交換，并且隨意地穿越并發(fā)的協(xié)議之間交互的安全層面的認(rèn)證機制。這個擴展是“簡單認(rèn)證和安全層”[SASL]的一個側(cè)面。</p><p>　　2、這個文檔用到的協(xié)定</p><p>　　在以下的這些

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

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

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

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

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

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

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

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

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

101、狀態(tài)是服務(wù)器發(fā)出了一個220服務(wù)的問候之后）。服務(wù)器MUST命令將拋棄所有的不是通過客戶端而得到的認(rèn)知，比如不是通過SASL本身而獲得認(rèn)知的EHLO命令的論點?？蛻舳说腗UST命令將拋棄所有的從服務(wù)器獲得的認(rèn)知，例如不是通過SASL本身而獲得的簡單郵件傳輸協(xié)議服務(wù)擴展的隊列。客戶端的SHOULD在SASL商議成功之后，發(fā)出一個EHLO命令作為第一個命令，這些將使得安全層級得到授權(quán)。</p><p>　　服務(wù)器不一

102、定要求支持任何的認(rèn)證機制，而認(rèn)證機制也不一定要支持所有的安全層。如果一個認(rèn)證命令失敗了，客戶端將試圖執(zhí)行另一個認(rèn)證機制的認(rèn)證命令。</p><p>　　一個Base64編碼的字符串通常來說是沒有長度限制的。只要由認(rèn)證機制產(chǎn)生的受客戶端和服務(wù)器支持的命令和響應(yīng)，客戶端和服務(wù)器端須支持，而不依賴于服務(wù)器或者客戶端的、可能存在于協(xié)議實現(xiàn)的某些方面的行長度的限制。</p><p><b>

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