RFC 1725

RFC 1725: Post Office Protocol - Version 3 💌

Okay bestie, RFC 1725 is called Post Office Protocol - Version 3 📬 and it's a Standards Track doc from November 1994. The authors are J. Myers at Carnegie Mellon and M. Rose at Dover Beach Consulting, Inc. 🎀 It obsoletes RFC 1460 💅, and the memo itself says it's a revision of RFC 1460, which was a Draft Standard. 🌸

Status of This Memo ✨

This doc specifies an Internet standards track protocol for the Internet community, and it wants your discussion and suggestions for improvements 🫶 For the 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. 🌈

Overview

Here's the tea ☕ This memo revises RFC 1460, and these are the changes:

• Removed the text about the "split-UA model", since it didn't add anything to understanding POP 💀
• Clarified the syntax of commands, keywords, and arguments ✨
• Clarified the behavior on a broken connection 🔌
• Explicitly permitted an inactivity autologout timer ⏰
• Clarified the requirements of the "exclusive-access lock" 🔒
• Removed the implementation-specific wording about parsing the maildrop 🧹
• Allowed servers to close the connection after a failed authentication command 🚪
• Removed the LAST command 👋
• Fixed a typo in the example of the TOP command ✏️
• Clarified that the second argument to the TOP command is non-negative 🔢
• Added the optional UIDL command 🦋
• Added a warning about the length of shared secrets with APOP ⚠️
• Added more warnings to the security considerations section 🔥

---

1. Introduction ✨

Okay so, on certain smaller nodes in the Internet it's often impractical to run a message transport system (MTS) 🥺 A workstation might not have enough resources (cycles, disk space) to keep an SMTP server [RFC821] and its local mail delivery system resident and running 24/7. And it can be expensive, or even impossible, to keep a personal computer connected to an IP-style network for long stretches (the node is missing the resource known as "connectivity") 📡

Even so, managing mail on these smaller nodes is super useful, and they often run a user agent (UA) to help with mail handling 💌 So the fix is that a node which can support an MTS entity offers a maildrop service to these less endowed nodes 🧚 The Post Office Protocol - Version 3 (POP3) lets a workstation dynamically access a maildrop on a server host in a useful way. Usually that means the workstation uses POP3 to retrieve the mail the server is holding for it 📥

For the rest of this memo, the term "client host" means a host using the POP3 service, and the term "server host" means a host that offers the POP3 service 💜

2. A Short Digression

This memo doesn't specify how a client host puts mail into the transport system, but it does share a method that fits the philosophy of this memo 👀

When the user agent on a client host wishes to enter a message into the transport system, it establishes an SMTP connection to its relay host (this relay host could be, but need not be, the POP3 server host for the client host).

3. Basic Operation

Here's how it starts 🎬 The server host kicks off the POP3 service by listening on TCP port 110. When a client host wants to use the service, it opens a TCP connection with the server host. Once the connection is established, the POP3 server sends a greeting. After that, the client and POP3 server trade commands and responses (respectively) until the connection is closed or aborted 🤝

Commands in POP3 are made up of a keyword, possibly followed by one or more arguments. Every command ends with a CRLF pair. Keywords and arguments are made of printable ASCII characters, and each one is separated from the next by a single SPACE character. Keywords are three or four characters long, and each argument can be up to 40 characters long 🔤

Responses in POP3 have a status indicator and a keyword, possibly followed by extra info. Every response ends with a CRLF pair too. There are currently two status indicators: positive (+OK) and negative (-ERR) ✅❌

Some responses are multi-line, and the doc clearly marks which ones 📜 For those, the server sends the first line and a CRLF, then any extra lines, each ending in a CRLF pair. When every line has been sent, it sends a final line made of a termination octet (decimal code 046, .) and a CRLF pair. If any line of a multi-line response begins with the termination octet, the server "byte-stuffs" that line by adding the termination octet in front of it. So a multi-line response ends with the five octets CRLF.CRLF 🫣

When the client reads a multi-line response, it checks whether each line begins with the termination octet. If it does, and octets other than CRLF follow, the client strips away the first octet (the termination octet) 🧽 If it does, and CRLF comes right after the termination character, the response from the POP server is over, and the line containing .CRLF isn't counted as part of the multi-line response 🏁

A POP3 session moves through a few states during its life 🌸 Once the TCP connection is open and the server has sent the greeting, the session enters the AUTHORIZATION state. In that state, the client has to identify itself to the POP3 server. Once that succeeds, the server grabs the resources tied to the client's maildrop, and the session enters the TRANSACTION state, where the client asks the server to do things. When the client sends the QUIT command, the session enters the UPDATE state. There, the POP3 server releases any resources it got during the TRANSACTION state and says goodbye 👋 Then the TCP connection gets closed 🔐

A POP3 server MAY have an inactivity autologout timer. That timer MUST be at least 10 minutes long. Receiving any command from the client during that interval should be enough to reset the timer. When the timer expires, the session does NOT enter the UPDATE state. Instead, the server should close the TCP connection without removing any messages or sending any response to the client 😴

4. The AUTHORIZATION State

Once a POP3 client opens the TCP connection, the POP3 server sends a one-line greeting 👋 It can be any string ending in CRLF. For example:

S:  +OK POP3 server ready

This greeting is a POP3 reply, so the POP3 server should always send a positive response as its greeting 🌟

Now the session is in the AUTHORIZATION state 🔑 The client must identify and authenticate itself to the POP3 server. This doc describes two ways to do it: the USER and PASS command combination, and the APOP command. APOP gets its own section later on 🧁

To authenticate with the USER and PASS combo, the client has to send the USER command first. If the POP3 server replies with a positive status indicator (+OK), the client can send either the PASS command to finish authenticating, or the QUIT command to end the POP3 session. If the server replies to USER with a negative status indicator (-ERR), the client can either try a new authentication command or send QUIT 🙃

When the client sends the PASS command, the POP3 server uses the argument pair from the USER and PASS commands to decide whether the client should get access to the right maildrop 🗝️

Once the POP3 server has decided, through any authentication command, that the client should get access to the right maildrop, it gets an exclusive-access lock on the maildrop, as needed to stop messages from being changed or removed before the session enters the UPDATE state 🔒 If the lock is acquired, the POP3 server sends a positive status indicator, and the session enters the TRANSACTION state with no messages marked as deleted 🎉 If the maildrop can't be opened for some reason (for example, a lock can't be acquired, the client is denied access to the right maildrop, or the maildrop can't be parsed), the POP3 server sends a negative status indicator. (If a lock was acquired but the POP3 server plans to send a negative status indicator, the POP3 server must release the lock before rejecting the command.) After sending a negative status indicator, the server may close the connection. If it doesn't, the client can either try a new authentication command and start over, or send the QUIT command 🔁

Once the POP3 server has opened the maildrop, it gives each message a message-number and notes the size of each message in octets 🔢 The first message in the maildrop gets message-number "1", the second gets "2", and so on, so the n'th message in a maildrop gets message-number "n". In POP3 commands and responses, all message-numbers and message sizes are written in base-10 (that is, decimal) 💅

Here are the summaries for the three POP3 commands we've covered so far 📋

USER name

   Arguments:
       a string identifying a mailbox (required), which is of
       significance ONLY to the server

   Restrictions:
       may only be given in the AUTHORIZATION state after the POP3
       greeting or after an unsuccessful USER or PASS command

   Possible Responses:
       +OK name is a valid mailbox
       -ERR never heard of mailbox name

   Examples:
       C: USER mrose
       S: +OK mrose is a real hoopy frood
          ...
       C: USER frated
       S: -ERR sorry, no mailbox for frated here

PASS string

   Arguments:
       a server/mailbox-specific password (required)

   Restrictions:
       may only be given in the AUTHORIZATION state after a
       successful USER command

   Discussion:
       Since the PASS command has exactly one argument, a POP3
       server may treat spaces in the argument as part of the
       password, instead of as argument separators.

   Possible Responses:
       +OK maildrop locked and ready
       -ERR invalid password
       -ERR unable to lock maildrop

   Examples:
       C: USER mrose
       S: +OK mrose is a real hoopy frood
       C: PASS secret
       S: +OK mrose's maildrop has 2 messages (320 octets)
          ...
       C: USER mrose
       S: +OK mrose is a real hoopy frood
       C: PASS secret
       S: -ERR maildrop already locked

QUIT

   Arguments: none

   Restrictions: none

   Possible Responses:
       +OK

   Examples:
       C: QUIT
       S: +OK dewey POP3 server signing off

5. The TRANSACTION State ✨

Okay so, once the client has successfully identified itself to the POP3 server and the server has locked and opened the right maildrop 🔐, the session is officially in the TRANSACTION state 💅. The client can now send any of the commands below, as many times as it wants, and the server replies after each one 🦋. Eventually the client sends QUIT and the session slides into the UPDATE state ✨.

Here are the POP3 commands that are valid in the TRANSACTION state 🎀:

STAT 📊

• Arguments: none
• Restrictions: may only be given in the TRANSACTION state

The server sends back a positive response with a line of info about the maildrop. That line is called a "drop listing" 🧾.

So parsing is easy, all POP3 servers are required to use one specific format for drop listings 💖. The positive response is "+OK" followed by a single space, the number of messages in the maildrop, another single space, and then the size of the maildrop in octets. This memo doesn't say anything about what comes after the maildrop size 🤷‍♀️. Minimal implementations should just end the line with a CRLF pair, and more advanced implementations are allowed to add other info.

NOTE: This memo STRONGLY discourages implementations from supplying additional information in the drop listing 🙈. Other, optional, facilities are discussed later on, and those are the ones that let the client parse the messages in the maildrop.

Also, messages marked as deleted don't get counted in either total 🗑️.

• Possible Responses:

+OK nn mm

• Examples:

C: STAT
S: +OK 2 320

LIST [msg] 📋

• Arguments: a message-number (optional), which, if present, may NOT refer to a message marked as deleted
• Restrictions: may only be given in the TRANSACTION state

If an argument is given and the server sends a positive response, that response has one line with info about that message. This line is called a "scan listing" for that message 🔍.

If no argument is given and the server sends a positive response, then the response is multi-line 📜. After the initial +OK, the server sends one line for each message in the maildrop, and each of those lines is also a "scan listing" for its message.

Again for easy parsing, all POP3 servers are required to use one specific format for scan listings 💅. A scan listing is the message-number, then a single space, then the exact size of the message in octets. This memo doesn't say anything about what comes after the message size in the scan listing. Minimal implementations should just end that line with a CRLF pair, and more advanced implementations can include other info parsed from the message ✨.

NOTE: This memo STRONGLY discourages implementations from supplying additional information in the scan listing 🙅‍♀️. Other, optional, facilities are discussed later on, and those are what let the client parse the messages in the maildrop.

Messages marked as deleted are not listed at all 👻.

• Possible Responses:

+OK scan listing follows
-ERR no such message

• Examples:

C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
  ...
C: LIST 2
S: +OK 2 200
  ...
C: LIST 3
S: -ERR no such message, only 2 messages in maildrop

RETR msg 📨

• Arguments: a message-number (required) which may not refer to a message marked as deleted
• Restrictions: may only be given in the TRANSACTION state

If the server sends a positive response, the response is multi-line 🌸. After the initial +OK, the server sends the message that matches the given message-number, and it has to be careful to byte-stuff the termination character (same as with every multi-line response) 🧚.

• Possible Responses:

+OK message follows
-ERR no such message

• Examples:

C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .

DELE msg 🗑️

• Arguments: a message-number (required) which may not refer to a message marked as deleted
• Restrictions: may only be given in the TRANSACTION state

The server marks the message as deleted 🚫. After that, any future command that refers to that message-number gets an error. The server doesn't actually delete the message until the session enters the UPDATE state, so it's not gone yet 🫶.

• Possible Responses:

+OK message deleted
-ERR no such message

• Examples:

C: DELE 1
S: +OK message 1 deleted
   ...
C: DELE 2
S: -ERR message 2 already deleted

NOOP 😴

• Arguments: none
• Restrictions: may only be given in the TRANSACTION state

The server does nothing at all, it just sends back a positive response 🫠.

• Possible Responses:

+OK

• Examples:

C: NOOP
S: +OK

RSET 🔄

• Arguments: none
• Restrictions: may only be given in the TRANSACTION state

Any messages the server marked as deleted get unmarked 🪄. Then the server sends a positive response. Iconic redo energy 💖.

• Possible Responses:

+OK

• Examples:

C: RSET
S: +OK maildrop has 2 messages (320 octets)

---

6. The UPDATE State 🌈

When the client sends the QUIT command from the TRANSACTION state, the session enters the UPDATE state 👑. (Quick heads up: if the client sends QUIT from the AUTHORIZATION state, the session ends but does NOT enter the UPDATE state 🙅‍♀️.)

If a session ends for some reason other than a client-sent QUIT, the session does NOT enter the UPDATE state, and it MUST not remove any messages from the maildrop 🛡️. Main character protection for your inbox 💜.

QUIT 👋

• Arguments: none
• Restrictions: none

The server removes all messages marked as deleted from the maildrop 💀. Then it releases any exclusive-access lock on the maildrop and replies with the status of those operations. After that, the TCP connection gets closed 🔒.

• Possible Responses:

+OK

• Examples:

C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
   ...
C: QUIT
S: +OK dewey POP3 server signing off (2 messages left)
   ...

7. Optional POP3 Commands ✨

okay so the commands we've covered so far are the ones every minimal POP3 server must be able to support, no excuses 💅

These optional ones are the fun part. They give the POP3 client way more freedom in how it handles messages, and the server still stays simple. Iconic, right? 🦋

NOTE: This memo STRONGLY encourages implementations to support these commands instead of building augmented drop and scan listings. The big philosophy here is to put the intelligence in the POP3 client and not in the POP3 server. 🧠💖

TOP msg n 🎀

Arguments:

• a message-number (required), which may NOT refer to a message marked as deleted, and a non-negative number (required)

Restrictions:

• may only be given in the TRANSACTION state

Discussion:

If the POP3 server gives a positive response, the response is multi-line. After the initial +OK, the server sends the headers of the message, the blank line that separates the headers from the body, and then however many lines of the body the client asked for. The server has to be careful to byte-stuff the termination character, same as with every other multi-line response 🫶

Heads up: if the number of lines the client requests is bigger than the number of lines in the body, the server just sends the entire message. No drama 💅

Possible Responses:

+OK top of message follows
-ERR no such message

Examples:

C: TOP 1 10
S: +OK
S: <the POP3 server sends the headers of the
   message, a blank line, and the first 10 lines
   of the body of the message>
S: .
   ...
C: TOP 100 3
S: -ERR no such message

UIDL [msg] 🔥

Arguments:

• a message-number (optionally). If a message-number is given, it may NOT refer to a message marked as deleted.

Restrictions:

• may only be given in the TRANSACTION state.

Discussion:

If an argument was given and the POP3 server gives a positive response, the response includes a line with information for that message. That line is called a "unique-id listing" for that message 🌸

If no argument was given and the POP3 server gives a positive response, the response is multi-line. After the initial +OK, the server sends one line for each message in the maildrop, and each line has information for that message. Each of those lines is also called a "unique-id listing" 💜

To keep parsing simple, all POP3 servers are required to use a certain format for unique-id listings. A unique-id listing is the message-number of the message, then a single space, then the unique-id of the message. Super predictable, love that for us ✨

Nothing else goes after the unique-id in the listing.

The unique-id is an arbitrary string picked by the server. It uses characters in the range 0x21 to 0x7E, it uniquely identifies a message inside a maildrop, and it sticks around across sessions. The server should never reuse a unique-id in a given maildrop, for as long as the thing using that unique-id exists. Main character energy for identifiers 👑

Note that messages marked as deleted are not listed. Bye bye, deleted messages 🙈

Possible Responses:

+OK unique-id listing follows
-ERR no such message

Examples:

C: UIDL
S: +OK
S: 1 whqtswO00WBw418f9t5JxYwZ
S: 2 QhdPYR:00WBw1Ph7x7
S: .
   ...
C: UIDL 2
S: +OK 2 QhdPYR:00WBw1Ph7x7
   ...
C: UIDL 3
S: -ERR no such message, only 2 messages in maildrop

APOP name digest 🔐

Arguments:

• a string identifying a mailbox and an MD5 digest string (both required)

Restrictions:

• may only be given in the AUTHORIZATION state after the POP3 greeting

Discussion:

Normally every POP3 session starts with a USER/PASS exchange. That sends a server- and user-id-specific password in the clear over the network 😭 For occasional use, that might not be a huge risk. But lots of POP3 clients connect to the server regularly to check for new mail, sometimes as often as every five minutes or so. So the chance of the password getting captured goes way up 💀

So we need another way to authenticate, one that gives origin authentication and replay protection without sending a password in the clear. That's exactly what the APOP command is for ✨

A POP3 server that implements APOP puts a timestamp in its banner greeting. The timestamp follows the syntax of the msg-id in [RFC822], and it MUST be different each time the POP3 server sends a banner greeting. Super important, no repeats allowed 🙅‍♀️ For example, on a UNIX setup where each POP3 server instance runs as its own UNIX process, the timestamp might look like this:

<process-ID.clock@hostname>

Here, process-ID is the decimal value of the process's PID, clock is the decimal value of the system clock, and hostname is the fully-qualified domain name of the host the POP3 server is running on 🧚

The POP3 client notes that timestamp, then issues the APOP command. The name parameter works exactly like the name parameter of the USER command. The digest parameter is made by running the MD5 algorithm [RFC1321] over a string made of the timestamp (angle-brackets included) followed by a shared secret. The shared secret is a string that only the POP3 client and server know. Take real care to keep the secret away from unauthorized people, because anyone who knows it can pretend to be the named user 🚨 The digest itself is a 16-octet value, sent in hexadecimal, using lower-case ASCII characters.

When the POP3 server gets the APOP command, it checks the digest. If the digest is correct, the server gives a positive response and the POP3 session moves into the TRANSACTION state 🎉 If not, the server gives a negative response and the session stays in the AUTHORIZATION state.

Also, the longer the shared secret is, the harder it is to figure out. So shared secrets should be long strings, way longer than the 8-character example below 💪

Possible Responses:

+OK maildrop locked and ready
-ERR permission denied

Examples:

S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octets)

In this example, the shared secret is the string tanstaaf. So the MD5 algorithm gets applied to this string:

<1896.697170952@dbc.mtview.ca.us>tanstaaf

which gives a digest value of:

c4c9334bac560ecc979e58001b3e22fb

---

8. POP3 Command Summary 📝

Here's the cheat sheet. Bookmark it, bestie 🔖

Minimal POP3 Commands:

USER name               valid in the AUTHORIZATION state
PASS string
QUIT

STAT                    valid in the TRANSACTION state
LIST [msg]
RETR msg
DELE msg
NOOP
RSET

QUIT                    valid in the UPDATE state

Optional POP3 Commands:

APOP name digest        valid in the AUTHORIZATION state

TOP msg n               valid in the TRANSACTION state
UIDL [msg]

POP3 Replies:

+OK
-ERR

Note that, apart from the STAT, LIST, and UIDL commands, the POP3 server's reply to any command only matters for "+OK" and "-ERR". Any text after that reply can be ignored by the client 💖

---

9. Example POP3 Session 🦋

Here's a full session from start to finish, so you can see how it all flows together 🌈

S: <wait for connection on TCP port 110>
C: <open connection>
S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
S:    +OK mrose's maildrop has 2 messages (320 octets)
C:    STAT
S:    +OK 2 320
C:    LIST
S:    +OK 2 messages (320 octets)
S:    1 120
S:    2 200
S:    .
C:    RETR 1
S:    +OK 120 octets
S:    <the POP3 server sends message 1>
S:    .
C:    DELE 1
S:    +OK message 1 deleted
C:    RETR 2
S:    +OK 200 octets
S:    <the POP3 server sends message 2>
S:    .
C:    DELE 2
S:    +OK message 2 deleted
C:    QUIT
S:    +OK dewey POP3 server signing off (maildrop empty)
C:  <close connection>
S:  <wait for next connection>

---

10. Message Format 💌

Every message sent during a POP3 session is assumed to follow the standard for the format of Internet text messages [RFC822] 📬

Here's something to watch for: the octet count a message has on the server host might be different from the octet count assigned to it, because of local rules for marking end-of-line. Usually, during the AUTHORIZATION state, the POP3 server can work out the size of each message in octets when it opens the maildrop 🧮 For example, if the server's host stores end-of-line as one character, the server just counts each occurrence of that character as two octets. Lines that start with the termination octet don't need to be counted twice, since the POP3 client removes all byte-stuffed termination characters when it gets a multi-line response ✨

---

11. References 📚

[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.

[RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982.

[RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April, 1992.

---

12. Security Considerations 🔐💀

This part is serious, bestie, so pay attention 🚨

It's conjectured that the APOP command gives origin identification and replay protection for a POP3 session. Because of that, a POP3 server that implements both the PASS and APOP commands must not allow both methods of access for a given user. For a given "USER name", either the PASS or the APOP command is allowed, but not both 🙅‍♀️

Also, the longer the shared secret is, the harder it is to derive it.

Servers that answer -ERR to the USER command are giving potential attackers clues about which names are valid 👀

Using the PASS command sends passwords in the clear over the network. Yikes 😭

Using the RETR and TOP commands sends mail in the clear over the network too. Anyone watching the wire can read it 💌

Otherwise, this memo doesn't discuss any other security issues.

That's the end of the security section, and honestly it's giving cautionary tale 🌈💜

13. Acknowledgements ✨

okay so the POP family has a long and kinda messy history 😭 POP3 is mainly a minor revision of RFC 1460, but it's also built on the ideas from RFCs 918, 937, and 1081. the whole lineage is giving generations of iteration 💅

also huge shoutout to Alfred Grimstad, Keith McCloghrie, and Neil Ostroff 🫶 they gave really significant comments on the APOP command, and that's a major glow-up moment for the spec 🌸

14. Authors' Addresses 🎀

here are the two bestie authors:

John G. Myers Carnegie-Mellon University 5000 Forbes Ave Pittsburgh, PA 15213

EMail: jgm+@cmu.edu

---

Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186

EMail: mrose@dbc.mtview.ca.us

That's the whole thing, bestie! 🌈🦋👑