RFC 2384

POP URL Scheme 💖

Part 1 of 2 🎀

Okay bestie, the title block first. 🧚 This is RFC 2384, written by R. Gellens (Randall Gellens) at QUALCOMM, Incorporated for the Network Working Group. It's a Standards Track doc, dated August 1998. The header doesn't list anything it obsoletes or updates, so it doesn't touch any other RFCs 🙈

---

Status of this Memo ✨

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅

Copyright Notice 🌸

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

1. Introduction ✨

Let's start with [POP3] 📮, which is a super widely deployed mail access protocol. Tons of programs read POP3 message stores, so they all need POP3 configuration info. The thing is, you need several config pieces just to open a mailbox, so one single string that holds them all is seriously convenient 🫶

A POP3 mailbox is a network resource, kind of like an [IMAP4] mailbox. URLs are the widely supported way to represent network resources, so it's giving obvious match 🦋

Having a way to write a POP3 mailbox as a URL will probably be useful in lots of programs and protocols. [ACAP] is one example where you need a string that packs up everything required to reach a network service. For instance, an [IMAP4] message store usually shows up in ACAP datasets as an [IMAP-URL] 🍓

So this memo defines a URL scheme for pointing at a POP mailbox. Iconic 👑

2. Conventions Used in this Document 💜

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be read as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. Read those carefully, they're the rules of the whole game 🔥

3. POP Scheme 🎀

The POP URL scheme points at a POP server. It can optionally include a port number, an authentication mechanism, an authentication ID, and/or an authorization ID ✨

A POP URL follows the common Internet scheme syntax from RFC 1738 [BASIC-URL], with one big exception: clear text passwords are not permitted 🚫 If :<port> is left out, the port defaults to 110.

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

A POP URL looks like this in general form:

pop://<user>;auth=<auth>@<host>:<port>

Here <user>, <host>, and <port> mean what they mean in RFC 1738. Some or all of the elements may be left out, except for pop:// and <host>, which always stick around 🧚

4. POP User Name and Authentication Mechanism 💅

An authorization identity (which mailbox to access) and an authentication identity (whose password gets checked) can both be supplied. We'll just call that the "user name" for simplicity. An authentication mechanism name can be supplied too. These get used in a "USER", "APOP", "AUTH" [POP-AUTH], or extension command after the client connects to the POP server 🔌 If the URL doesn't include an authentication identifier, the program reading the POP URL SHOULD ask the user for one 🙋‍♀️

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

When an <enc-auth-type> is specified, the client SHOULD request appropriate credentials from that mechanism, and it should 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=* means the client SHOULD pick an appropriate authentication mechanism on its own. It MAY use any mechanism the POP server supports 🌈

If you specify an <enc-auth-type> other than ;AUTH=*, the client SHOULD NOT switch to a different mechanism without explicit user permission. Don't be sneaky, bestie 🙅‍♀️

If a user name comes with no authentication mechanism, then ;AUTH=* gets assumed 🍓

Now, this part is serious, so put your listening ears on 👂 URLs can easily come from untrusted sources, so you have to be careful whenever you resolve a URL that requires or requests any kind of authentication. If your credentials get sent to the wrong server, your account's security could be compromised 😭 The program resolving the URL should make sure it meets at least one of these criteria:

1. The URL comes from a trusted source, like a referral server that the client has validated and trusts under site policy. Note that a user typing the URL in may or may not count as a trusted source, depending on the user's experience level and site policy.
2. Explicit local site policy lets the client connect to the server in the URL. For example, if the client knows the site domain name, site policy might say any hostname ending in that domain is trusted.
3. The user confirms that connecting to that domain name with the specified credentials and/or mechanism is permitted.
4. A mechanism is used that validates the server before potentially compromising client credentials are passed along.
5. An authentication mechanism is used that won't reveal information to the server that could be used to compromise future connections.

⚠️ A URL containing ;AUTH=* should be treated with extra care, because it might fall back on a weaker security mechanism. Also, clients are discouraged from using a plain text password as a fallback with ;AUTH=* unless the connection has strong encryption (for example, a key length greater than 56 bits) 🔐

Heads up on characters too: if unsafe or reserved characters like " " or ";" show up in the user name or the authentication mechanism, they MUST be encoded as described in RFC 1738 [BASIC-URL]. No skipping this one, periodt 💀

5. Relative POP URLs 🌸

Relative POP URLs are not permitted. Always full URLs, always 💅

6. Multinational Considerations 🌍

8-bit characters aren't allowed in URLs, so [UTF8] characters get encoded the way the URL specification [BASIC-URL] requires. Global vibes, encoded properly 🧚

---

13. Full Copyright Statement ✨

Okay bestie, legal stuff but make it cute 🎀

Copyright (C) The Internet Society (1998). All Rights Reserved. 💅

So here's the deal. You can copy this document and hand it out to anyone, and you can make derivative works that comment on it, explain it, or help people implement it 🦋. You can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind. The one catch is that the copyright notice and this paragraph have to be on every copy and every derivative work 🫶.

BUT the document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions, though 🌸. The first is for developing Internet standards, and in that case the copyright procedures in the Internet Standards process must be followed. The second is if you need 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. 💖

Last but not least, the document and the info in it are provided on an "AS IS" basis, and the Internet Society and the Internet Engineering Task Force are basically saying they don't promise anything, no matter how much you ask nicely 💀 👇

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.