The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism
RFC 5034

Document Type RFC - Proposed Standard (July 2007; No errata)
Obsoletes RFC 1734
Updates RFC 2449
Was draft-siemborski-rfc1734bis (individual in gen area)
Authors Rob Siemborski  , Abhijit Menon-Sen 
Last updated 2018-12-20
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 5034 (Proposed Standard)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Lisa Dusseault
Send notices to
Network Working Group                                      R. Siemborski
Request for Comments: 5034                                  Google, Inc.
Obsoletes: 1734                                             A. Menon-Sen
Updates: 2449                                     Oryx Mail Systems GmbH
Category: Standards Track                                      July 2007

                    The Post Office Protocol (POP3)
Simple Authentication and Security Layer (SASL) Authentication Mechanism

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 IETF Trust (2007).


   This document defines a profile of the Simple Authentication and
   Security Layer (SASL) for the Post Office Protocol (POP3).  This
   extension allows a POP3 client to indicate an authentication
   mechanism to the server, perform an authentication protocol exchange,
   and optionally negotiate a security layer for subsequent protocol
   interactions during this session.

   This document seeks to consolidate the information related to POP3
   AUTH into a single document.  To this end, this document obsoletes
   and replaces RFC 1734, and updates the information contained in
   Section 6.3 of RFC 2449.

Siemborski & Menon-Sen      Standards Track                     [Page 1]
RFC 5034           POP3 SASL Authentication Mechanism          July 2007

1.  Introduction

   The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered
   several problems in its specification.  The first is that it was very
   similar to a SASL framework defined by [RFC4422], but pre-dated the
   initial SASL specification.  It was therefore missing some key
   components, such as a way to list the available authentication

   Later, [RFC2449] attempted to remedy this situation by adding the
   CAPA command and allowing an initial client response with the AUTH
   command, but problems remained in the clarity of the specification of
   how the initial client response was to be handled.

   Together, this means creating a full POP3 AUTH implementation
   requires an understanding of material in at least five different
   documents (and [RFC3206] provides additional response codes that are
   useful during authentication).

   This document attempts to combine the information in [RFC1734] and
   [RFC2449] to simplify this situation.  Additionally, it aims to
   clarify and update the older specifications where appropriate.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   Formal syntax is defined by [RFC4234].

3.  The SASL Capability

   This section supersedes the definition of the SASL Capability in
   section 6.3 of [RFC2449].

   CAPA tag:

      Supported SASL Mechanisms

   Added commands:

Siemborski & Menon-Sen      Standards Track                     [Page 2]
RFC 5034           POP3 SASL Authentication Mechanism          July 2007

   Standard commands affected:

   Announced states / possible differences:
      both / no

   Commands valid in states:

   Specification reference:
      This document and [RFC4422]

      The SASL capability permits the use of the AUTH command (as
      defined in Section 4 of this document) to begin a SASL negotiation
      (as defined in [RFC4422]).  The argument to the SASL capability is
      a space-separated list of SASL mechanisms that are supported.

      If a server either does not support the CAPA command or does not
      advertise the SASL capability, clients SHOULD NOT attempt the AUTH
      command.  If a client does attempt the AUTH command in such a
      situation, it MUST NOT supply the client initial response
      parameter (for backwards compatibility with [RFC1734]).

      Note that the list of available mechanisms MAY change after a
      successful STLS command (see [RFC2595]).  However, as required by
      [RFC2449], implementations MUST continue to include the SASL
      capability even after a successful AUTH command has been completed
      (even though no further AUTH commands may be issued).

      S: +OK BlurdyBlurp POP3 server ready
      C: CAPA
      S: +OK List of capabilities follows
      S: STLS
      S: IMPLEMENTATION BlurdyBlurp POP3 server
Show full document text