rfc2554_smtp_auth.txt

邮件编码格式说明。

   This response to the AUTH command indicates that the authentication
   failed due to a temporary server failure.

   530 Authentication required

   This response may be returned 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.


















Myers                       Standards Track                     [Page 6]

RFC 2554                  SMTP Authentication                 March 1999


7. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   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 case-insensitive fashion.

   UPALPHA         = %x41-5A            ;; Uppercase: A-Z

   LOALPHA         = %x61-7A            ;; Lowercase: a-z

   ALPHA           = UPALPHA / LOALPHA  ;; case insensitive

   DIGIT           = %x30-39            ;; Digits 0-9

   HEXDIGIT        = %x41-46 / DIGIT    ;; hexidecimal digit (uppercase)

   hexchar         = "+" HEXDIGIT HEXDIGIT

   xchar           = %x21-2A / %x2C-3C / %x3E-7E
                     ;; US-ASCII except for "+", "=", SPACE and CTL

   xtext           = *(xchar / hexchar)

   AUTH_CHAR       = ALPHA / DIGIT / "-" / "_"

   auth_type       = 1*20AUTH_CHAR

   auth_command    = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
                     *(CRLF [base64]) CRLF

   auth_param      = "AUTH=" xtext
                       ;; The decoded form of the xtext MUST be either
                       ;; an addr-spec or the two characters "<>"

   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




Myers                       Standards Track                     [Page 7]

RFC 2554                  SMTP Authentication                 March 1999


   CR              = %x0C           ;; ASCII CR, carriage return

   CRLF            = CR LF

   CTL             = %x00-1F / %x7F ;; any ASCII control character and DEL

   LF              = %x0A           ;; ASCII LF, line feed

   SPACE           = %x20           ;; ASCII SP, space




8. References

   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, November 1997.

   [CRAM-MD5]  Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
               AUTHorize Extension for Simple Challenge/Response", RFC
               2195, September 1997.

   [ESMTP]     Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
               Crocker, "SMTP Service Extensions", RFC 1869, November
               1995.

   [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
               Notifications", RFC 1891, January 1996.

   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [SASL]      Myers, J., "Simple Authentication and Security Layer
               (SASL)", RFC 2222, October 1997.

   [SUBMIT]    Gellens, R. and J. Klensin, "Message Submission", RFC
               2476, December 1998.

   [RFC821]    Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
               821, August 1982.

   [RFC822]    Crocker, D., "Standard for the Format of ARPA Internet
               Text Messages", STD 11, RFC 822, August 1982.








Myers                       Standards Track                     [Page 8]

RFC 2554                  SMTP Authentication                 March 1999


9. Security Considerations

   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 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 support the Authentication extension or causing
   all AUTH commands to fail.

   Before the SASL negotiation has begun, any protocol interactions are
   performed 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 results in a security layer.

   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
   an relayed message without an envelope authentication to pick up the
   authentication of the relay client.

   A message submission client may require the user to authenticate
   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 anonymous submission.

   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 problem than end-to-end
   systems; it has the following key differences:

      (1) it is generally useful only within a trusted enclave

      (2) it protects the entire envelope of a message, not just the
          message's body.

      (3) it authenticates the message submission, not authorship of the
          message content

      (4) it can give the sender some assurance the message was
          delivered to the next hop in the case where the sender
          mutually authenticates with the next hop and negotiates an
          appropriate security layer.




Myers                       Standards Track                     [Page 9]

RFC 2554                  SMTP Authentication                 March 1999


   Additional security considerations are mentioned in the SASL
   specification [SASL].



10. Author's Address

   John Gardiner Myers
   Netscape Communications
   501 East Middlefield Road
   Mail Stop MV-029
   Mountain View, CA 94043

   EMail: [e-mail]





































Myers                       Standards Track                    [Page 10]

RFC 2554                  SMTP Authentication                 March 1999


11.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Myers                       Standards Track                    [Page 11]