POP URL Scheme
RFC 2384

Document Type RFC - Proposed Standard (August 1998; Errata)
Was draft-gellens-pop-url (individual)
Author Randall Gellens 
Last updated 2020-01-21
Stream Legacy
Formats plain text html pdf htmlized with errata bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2384 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        R. Gellens
Request for Comments: 2384                       QUALCOMM, Incorporated
Category: Standards Track                                   August 1998

                             POP URL Scheme

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 (1998).  All Rights Reserved.

1.  Introduction

   [POP3] is a widely-deployed mail access protocol.  Many programs
   access POP3 message stores, and thus need POP3 configuration
   information.  Since there are multiple configuration elements which
   are required in order to access a mailbox, a single string
   representation is convenient.

   A POP3 mailbox (like an [IMAP4] mailbox) is a network resource, and
   URLs are a widely-supported generalized representation of network

   A means of specifying a POP3 mailbox as a URL will likely be useful
   in many programs and protocols. [ACAP] is one case where a string
   encapsulation of elements required to access network services is
   needed.  For example, an [IMAP4] message store is usually specified
   in ACAP datasets as an [IMAP-URL].

   This memo defines a URL scheme for referencing a POP mailbox.

2.  Conventions Used in this Document

   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].

Gellens                     Standards Track                     [Page 1]
RFC 2384                     POP URL Scheme                  August 1998

3.  POP Scheme

   The POP URL scheme designates a POP server, and optionally a port
   number, authentication mechanism, authentication ID, and/or
   authorization ID.

   The POP URL follows the common Internet scheme syntax as defined in
   RFC 1738 [BASIC-URL] except that clear text passwords are not
   permitted.  If :<port> is omitted, the port defaults to 110.

   The POP URL is described using [ABNF] in Section 8.

   A POP URL is of the general form:


   Where <user>, <host>, and <port> are as defined in RFC 1738, and some
   or all of the elements, except "pop://" and <host>, may be omitted.

4.  POP User Name and Authentication Mechanism

   An authorization (which mailbox to access) and authentication (whose
   password to check against) identity (referred to as "user name" for
   simplicity) and/or authentication mechanism name may be supplied.
   These are used in a "USER", "APOP", "AUTH" [POP-AUTH], or extension
   command after making the connection to the POP server.  If the URL
   doesn't supply an authentication identifier, the program interpreting
   the POP URL SHOULD request one from the user.

   An authentication mechanism can be expressed by adding ";AUTH=<enc-
   auth-type>" to the end of the user name.  If the authentication
   mechanism name is not preceded by a "+", it is a SASL POP [SASL]
   mechanism.  If it is preceded by a "+", it is either "APOP" or an
   extension mechanism.

   When an <enc-auth-type> is specified, the client SHOULD request
   appropriate credentials from that mechanism and use the "AUTH",
   "APOP", or extension command instead of the "USER" command.  If no
   user name is specified, one SHOULD be obtained from the mechanism or
   requested from the user as appropriate.

   The string ";AUTH=*" indicates that the client SHOULD select an
   appropriate authentication mechanism.  It MAY use any mechanism
   supported by the POP server.

   If an <enc-auth-type> other than ";AUTH=*" is specified, the client
   SHOULD NOT use a different mechanism without explicit user

Gellens                     Standards Track                     [Page 2]
RFC 2384                     POP URL Scheme                  August 1998

   If a user name is included with no authentication mechanism, then
   ";AUTH=*" is assumed.

   Since URLs can easily come from untrusted sources, care must be taken
   when resolving a URL which requires or requests any sort of
   authentication.  If authentication credentials are supplied to the
   wrong server, it may compromise the security of the user's account.
   The program resolving the URL should make sure it meets at least one
   of the following criteria in this case:

   (1) The URL comes from a trusted source, such as a referral server
   which the client has validated and trusts according to site policy.
   Note that user entry of the URL may or may not count as a trusted
   source, depending on the experience level of the user and site
Show full document text