SMTP Service Extension for Authentication
RFC 2554

Document Type RFC - Proposed Standard (March 1999; No errata)
Obsoleted by RFC 4954
Was draft-myers-smtp-auth (individual)
Author John Myers 
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2554 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           J. Myers
Request for Comments: 2554                       Netscape Communications
Category: Standards Track                                     March 1999

                         SMTP Service Extension
                           for Authentication

Status of this Memo

   This document specifies an Internet standards track 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 standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

1. Introduction

   This document 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 negotiate
   a security layer for subsequent protocol interactions.  This
   extension is a profile of the Simple Authentication and Security
   Layer [SASL].

2. Conventions Used in this Document

   In examples, "C:" 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 are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [KEYWORDS].

3. The Authentication service extension

   (1) the name of the SMTP service extension is "Authentication"

   (2) the EHLO keyword value associated with this extension is "AUTH"

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

   (3) The AUTH EHLO keyword contains as a parameter a space separated
       list of the names of supported SASL mechanisms.

   (4) a new SMTP verb "AUTH" is defined

   (5) an optional parameter using the keyword "AUTH" is added to the
       MAIL FROM command, and extends the maximum line length of the
       MAIL FROM command by 500 characters.

   (6) this extension is appropriate for the submission protocol

4. The AUTH command

   AUTH mechanism [initial-response]

         a string identifying a SASL authentication mechanism.
         an optional base64-encoded response

         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 a 503 reply.

         The AUTH command is not permitted during a mail transaction.

         The AUTH command indicates an authentication mechanism to 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 subsequent protocol
         interactions.  If the requested authentication mechanism is not
         supported, the server rejects the AUTH command with a 504

         The authentication protocol exchange consists of a series 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.  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
         MUST reject the AUTH command by sending a 501 reply.

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

         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.
         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 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 to the AUTH
         command with a mechanism that sends data in the initial
         challenge, the server rejects the AUTH command with a 535

         If the server cannot BASE64 decode the argument, it rejects the
Show full document text