【正文】 isms is too weak.This response to the AUTH mand indicates that the selected authentication mechanism is weaker than server policy permits for that user.538 Encryption required for requested authentication mechanismThis response to the AUTH mand indicates that the selected authentication mechanism may only be used when the underlying SMTP connection is encrypted.454 Temporary authentication failuresThis response to the AUTH mand indicates that the authentication failed due to a temporary server failure.530 Authentication requiredThis response may be returned by any mand other than AUTH, EHLO, HELO, NOOP, RSET, or QUIT. It indicates that server policy requires authentication in order to perform the requested action.7. Formal SyntaxThe following syntax specification uses the augmented BackusNaur Form (BNF) notation as specified in [ABNF].Except as noted otherwise, all alphabetic characters are case insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a caseinsensitive fashion.8. Security ConsiderationsSecurity 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 mail to that server when the connection is not mutually authenticated and encrypted. Otherwise, an attacker could steal the client39。外文資料原文SMTP Service Extension for AuthenticationRFC 2554This document specifies an Internet standards track protocol for the Internet munity, and requests 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. Distribution of this memo is unlimited.There are usually two operating modes: SMTP to send and receive SMTP. Specific way: to send SMTP mail in the received user request to determine whether this local mail, if sent to the user39。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 argument to the EHLO mand, which was not obtained from the SASL negotiation itself. The client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the SASL negotiation itself (with the exception that a client MAY pare the list of advertised SASL mechanisms before and after authentication in order to detect an active downnegotiation attack). The client SHOULD send an EHLO mand as the first mand after a successful SASL negotiation which results in the enabling of a security layer.The server is not required to support any particular authentication mechanism, nor are authentication mechanisms required to support any security layers. If an AUTH mand fails, the client may try another authentication mechanism by issuing another AUTH mand.If an AUTH mand fails, the server MUST behave the same as if the client had not issued the AUTH mand.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 any line length limitations the client or server may have in other parts of its protocol implementation.Examples:S: 220 ESMTP server readyC: EHLO S: S: 250 AUTH CRAMMD5 DIGESTMD5C: AUTH FOOBARS: 504 unrecognized authentication types.C: AUTH CRAMMD5S: 235 Authentication successful.5. The AUTH parameter to the MAIL FROM mandAUTH=addrspecArguments:An addrspec containing the identity which submitted the message to the delivery system, or the two character sequence , indicating such an identity is unknown or insufficiently authenticated.Discussion:The optional AUTH parameter to the MAIL FROM mand allows cooperating agents in a trusted environment to municate the authentication of individual messages.If the server trusts the authenticated identity of the client toAssert that the message was originally submitted by the supplied addrspec, and then the server SHOULD supply the same addrspec in an AUTH parameter when relaying the message to any server which supports the AUTH extension.A MAIL FROM parameter of AUTH= 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. If the AUTH parameter to the MAIL FROM is not supplied, the client has authenticated, and the server believes the message is an original submission by the client