POP URL Scheme
Extracted elements (17)
Clear text passwords are explicitly not permitted in POP URLs, even though RFC 1738's common Internet scheme syntax allows them, to protect user credentials from exposure when URLs are stored or transmitted.
The POP URL scheme was defined because accessing a POP3 mailbox requires multiple configuration elements (server, port, authentication mechanism, user identity), and a single string representation is convenient for programs and protocols such as ACAP that need to encapsulate network service access information.
Relative POP URLs are not permitted; only absolute POP URLs are defined by this scheme.
Since 8-bit characters are not permitted in URLs, UTF-8 characters are encoded as required by the URL specification (RFC 1738). This applies to user names and authentication mechanism names in POP URLs.
If a user name is included with no authentication mechanism, then ";AUTH=*" is assumed.
If an <enc-auth-type> other than ";AUTH=*" is specified, the client SHOULD NOT use a different mechanism without explicit user permission.
If :<port> is omitted from a POP URL, the port defaults to 110.
If the URL doesn't supply an authentication identifier, the program interpreting the POP URL SHOULD request one from the user.
If unsafe or reserved characters such as " " or ";" are present in the user name or authentication mechanism, they MUST be encoded as described in RFC 1738.
The string ";AUTH=*" indicates that the client SHOULD select an appropriate authentication mechanism, and MAY use any mechanism supported by the POP server.
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.
The auth parameter is expressed as ";AUTH=<enc-auth-type>" appended to the user name. If the mechanism name is not preceded by "+", it is a SASL mechanism; if preceded by "+", it is APOP or an extension mechanism.
The POP URL scheme designates a POP server and optionally a port number, authentication mechanism, authentication ID, and/or authorization ID. The general form is: pop://<user>;auth=<auth>@<host>:<port>. Clear text passwords are not permitted in POP URLs.
A URL containing ";AUTH=*" should be treated with extra care since it might fall back on a weaker security mechanism. Clients are discouraged from using a plain text password as a fallback with ";AUTH=*" unless the connection has strong encryption (e.g., key length greater than 56 bits).
Many email clients store the plain text password for later use after logging into a POP server. Such clients MUST NOT use a stored password in response to a POP URL without explicit permission from the user to supply that password to the specified host name.
Since URLs can easily come from untrusted sources, care must be taken when resolving a URL that requires authentication. If authentication credentials are supplied to the wrong server, it may compromise the security of the user's account. The resolving program must ensure the URL source is trusted, site policy permits connection, the user confirms the connection, the server is validated before passing credentials, or the mechanism will not reveal information usable to compromise future connections.
The POP URL is defined using ABNF. The top-level production is: pop-url = "pop://" server, where server = [user-auth "@"] hostport and user-auth = enc-user [auth]. The auth component uses the form ";AUTH=" followed by "*" or an enc-auth-type.