RFC 1460

RFC 1460: Post Office Protocol - Version 3 🎀

okay bestie, let's get the important stuff out of the way first 💅 This one is RFC 1460, titled "Post Office Protocol - Version 3". It was written by M. Rose at Dover Beach Consulting, Inc. for the Network Working Group, and it's dated June 1993. It's an IAB standards track protocol document 🦋 It obsoletes RFC 1225, which is the older version of this same protocol. Nothing in the header says it updates anything else.

---

Status of This Memo ✨

This RFC is an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the current standardization state and status, check the current edition of the "IAB Official Protocol Standards." Distribution of this memo is unlimited, so share it with everyone 🌈

Overview 🌸

This memo is a revision of RFC 1225, which was a Draft Standard. Here's what changed from that version:

• the RPOP facility is removed 💀;
• the optional APOP facility is added (which is in interoperable, operational use in at least three implementations) 🔥;
• a typo was corrected with respect to the interaction of LAST and RSET 🙈;
• section numbers were added; and,
• an acknowledgements section was added 💜

1. Introduction 🧚

Okay so, some smaller nodes on the Internet can't realistically 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 all the time. It's giving "too much for a tiny device."

A personal computer also might not be able to stay connected to an IP-style network for long stretches, or it could be expensive or impossible to do that. The node is missing what we call "connectivity" 💔

Even so, managing mail on these smaller nodes is super useful, and they usually have 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 mail the server is holding for it 📬

For the rest of this memo, a "client host" is a host using the POP3 service, and a "server host" is a host that offers the POP3 service. Simple, iconic ✨

2. A Short Digression 💅

This memo doesn't specify how a client host gets mail into the transport system. There is, however, a method that fits the philosophy of this memo, and it goes like this:

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

If that method is followed, the client host looks like a user agent to the MTS, and it should NOT be regarded as a "trusted" MTS entity in any sense whatsoever 👑 We'll come back to this idea and to the role of POP3 in a split-UA model later in the memo, so hold that thought ✨

3. Basic Operation 🦋

First, the server host starts 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 up, the POP3 server sends a greeting. After that, the client and the POP3 server swap commands and responses (respectively) until the connection is closed or aborted 🔥

POP3 commands are a keyword, possibly followed by an argument. Every command ends with a CRLF pair.

POP3 responses are a success indicator, then a keyword, possibly followed by more information. Every response ends with a CRLF pair too. There are currently two success indicators: positive (+OK) and negative (-ERR) 💖

Some commands get multi-line responses, and the memo clearly marks which ones below. For these, 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 one last line made of a termination octet (decimal code 046, .) and a CRLF pair. If any line of the multi-line response starts with the termination octet, that line gets "byte-stuffed," which means the termination octet gets added to the front of that line 🙈

So a multi-line response ends with the five octets CRLF.CRLF. When the client reads a multi-line response, it checks whether a line starts with the termination octet. If it does, and octets other than CRLF follow it, the client strips that first octet (the termination octet) off the line. If it does, and CRLF comes right after the termination character, then the POP server's response is over, and the .CRLF line doesn't count as part of the multi-line response ✨

A POP3 session goes through a few states during its life 🌈 Once the TCP connection is open and the POP3 server has sent the greeting, the session enters the AUTHORIZATION state. In that state the client must identify itself to the POP3 server. Once the client has done this successfully, the server grabs the resources tied to the client's maildrop, and the session enters the TRANSACTION state. In TRANSACTION, the client asks the POP3 server to do things. When the client is done with its transactions, the session enters the UPDATE state. There, the POP3 server releases any resources it grabbed during TRANSACTION and says goodbye 👋 Then the TCP connection closes.

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 that ends with CRLF. For example:

S.  +OK POP3 server ready

This greeting is a POP3 reply, and the POP3 server should always give a positive response as the greeting 💅

Now the session is in the AUTHORIZATION state, and the client has to issue the USER command next. If the server answers with a positive success indicator (+OK), the client can then either issue the PASS command to finish authorization, or issue the QUIT command to end the POP3 session. If the server answers the USER command with a negative success indicator (-ERR), the client can either send a new USER command or send QUIT 🙃

When the client issues 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 🔐 If it should, the POP3 server grabs an exclusive-access lock on the maildrop. If the lock is acquired, the POP3 server parses the maildrop into individual messages (see the note below). It figures out the last message (if there is one) in the maildrop that was referenced by the RETR command, and it responds with a positive success indicator. The session then enters the TRANSACTION state 🎉

If the lock can't be acquired, if the client is denied access to that maildrop, or if the maildrop can't be parsed for some reason, the POP3 server responds with a negative success indicator instead. (If a lock was acquired but the POP3 server is going to respond with a negative success indicator, the POP3 server must release the lock before rejecting the command.) At that point, the client can either send a new USER command and start over, or send QUIT 🫠

NOTE: Minimal implementations of the POP3 need only be able to break a maildrop into its component messages; they need NOT be able to parse individual messages. More advanced implementations may wish to have this capability, for reasons discussed later.

After the POP3 server has parsed the maildrop into individual messages, it gives each message a message-id and notes the size of the message in octets. The first message in the maildrop gets a message-id of "1", the second gets "2", and so on, so the n'th message in a maildrop gets a message-id of "n". In POP3 commands and responses, all message-ids and message sizes are written in base-10 (that is, decimal) 🔢

The server also sets the "highest number accessed" to the number of the last message referenced by the RETR command 📌

Here are the summaries for the three POP3 commands we've covered so far, all in one place for you 🍰

USER name
    Arguments: a server specific user-id (required)
    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 welcome here
        -ERR never heard of name
    Examples:
        C:    USER mrose
        S:    +OK mrose is a real hoopy frood

          ...
        C:    USER frated
        S:    -ERR sorry, frated doesn't get his mail here

PASS string
    Arguments: a server/user-id specific password (required)
    Restrictions: may only be given in the AUTHORIZATION
        state after a successful USER command
    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 unable to lock mrose's maildrop, file
              already locked

QUIT
    Arguments: none
    Restrictions: none
    Possible Responses:
        +OK
    Examples:
        C:    QUIT
        S:    +OK dewey POP3 server signing off

Part 1 of 4 is done, and we're just getting started 🌈✨ Part 2 is coming next, so stay tuned bestie 💖

5. The TRANSACTION State ✨

okay so once the client has successfully identified itself to the POP3 server and the POP3 server has locked and burst the appropriate maildrop, the session is now in the TRANSACTION state 💅 the client can now send any of the following POP3 commands over and over. after each command, the server sends back a response 🦋 eventually the client sends QUIT and the session enters 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.

Discussion:

the server sends a positive response with a line containing info about the maildrop 📬 this line is called a "drop listing" for that maildrop

to keep parsing simple, all POP3 servers are required to use a certain format for drop listings 🧚 the first octets present must show the number of messages in the maildrop, and then comes the size of the maildrop in octets. this memo makes no requirement on what comes after the maildrop size. minimal implementations should just end that line of the response with a CRLF pair, and more advanced implementations may include other info

NOTE: This memo STRONGLY discourages implementations from supplying additional information in the drop listing. Other, optional, facilities are discussed later on which permit the client to parse the messages in the maildrop. 🙈

also, messages marked as deleted are not counted in either total 💀

Possible Responses:

+OK nn mm

Examples:

C:    STAT
S:    +OK 2 320

---

LIST [msg]

Arguments: a message-id (optionally). If a message-id 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 server sends a positive response, then there's a line containing info for that message 🌸 this line is called a "scan listing" for that message

if no argument was given and the server sends a positive response, then the response is multi-line 💜 after the initial +OK, the server sends one scan listing line for each message in the maildrop

to keep parsing simple, all POP3 servers are required to use a certain format for scan listings ✨ the first octets present must be the message-id of the message, followed by the size of the message in octets. this memo makes no requirement on what comes after the message size in the scan listing. minimal implementations should just end that line of the response with a CRLF pair, and more advanced implementations may include other info, as 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 which permit the client to parse the messages in the maildrop. 🫠

messages marked as deleted are not listed, so don't look for them 🙃

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-id (required). This message-id may NOT refer to a message marked as deleted. 🚫 Restrictions: may only be given in the TRANSACTION state.

Discussion:

if the server sends a positive response, then the response is multi-line 📖 after the initial +OK, the server sends the message that goes with the given message-id, and it has to be careful to byte-stuff the termination character (same as with all multi-line responses) 🧷

if the number for this message is higher than the "highest number accessed" in the maildrop, the server updates the "highest number accessed" to that number 👑

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-id (required). This message-id may NOT refer to a message marked as deleted. 🙅‍♀️ Restrictions: may only be given in the TRANSACTION state.

Discussion:

the server marks the message as deleted 🗑️ any future reference to that message-id in a POP3 command gives an error. the server does not actually delete the message until the session enters the UPDATE state, so it's not gone yet, bestie 🥹

if the number for this message is higher than the "highest number accessed" in the maildrop, the server updates the "highest number accessed" to that number 👑

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.

Discussion:

the server does nothing at all, it just replies with a positive response 😴 literally the most chill command ever 🧘‍♀️

Possible Responses:

+OK

Examples:

C:    NOOP
S:    +OK

---

LAST

Arguments: none Restrictions: may only be issued in the TRANSACTION state.

Discussion:

the server sends a positive response with a line containing the highest message number which accessed 📈 if no message in the maildrop has been accessed during previous transactions, zero is returned 🌱 a client can then infer that messages, if any, numbered greater than the response to the LAST command are messages it hasn't accessed yet 🔍

Possible Response:

+OK nn

Examples:

C:      STAT
S:      +OK 4 320
C:      LAST
S:      +OK 1
C:      RETR 3
S:      +OK 120 octets
S:      <the POP3 server sends the entire message
        here>
S:      .
C:      LAST
S:      +OK 3
C:      DELE 2
S:      +OK message 2 deleted
C:      LAST
S:      +OK 3
C:      RSET
S:      +OK
C:      LAST
S:      +OK 0

---

RSET

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

Discussion:

if any messages were marked as deleted by the server, they get unmarked 🔄 the server then replies with a positive response. on top of that, the "highest number accessed" gets reset to zero 🫧 a total reset, babe 💅

Possible Responses:

+OK

Examples:

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

6. The UPDATE State 🌈

when the client issues the QUIT command from the TRANSACTION state, the session enters the UPDATE state 🚪 (heads up: if the client issues the QUIT command from the AUTHORIZATION state, the POP3 session terminates but does NOT enter the UPDATE state 🙈)

QUIT

Arguments: none Restrictions: none

Discussion:

the server removes all messages marked as deleted from the maildrop 🧹 then it releases the exclusive-access lock on the maildrop and replies about whether these operations worked. 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 POP3 commands we already covered must be supported by every minimal POP3 server, no exceptions 🫶

the optional ones below give the POP3 client way more freedom in handling messages, and the server stays simple. it's giving clean division of labour 💅

NOTE: This memo STRONGLY encourages implementations to support these commands in lieu of developing augmented drop and scan listings. In short, the philosophy of this memo is to put intelligence in the part of the POP3 client and not the POP3 server. 🧠💖

TOP msg n

Arguments: a message-id (required) and a number. This message-id may NOT refer to a message marked as deleted. 🙅‍♀️

Restrictions: may only be given in the TRANSACTION state.

Discussion:

ok so if the server says yes (positive response), the reply is multi-line 🌸 after the initial +OK, the server sends the headers of the message, then the blank line that separates the headers from the body, then however many lines of body you asked for. and it has to byte-stuff the termination character, same as every other multi-line response 🎀

also, if you ask for more lines than the body actually has, you just get the whole message. no drama 🦋

Possible Responses:

+OK top of message follows
-ERR no such message

Examples:

C:    TOP 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
S:    -ERR no such message

APOP name digest

Arguments: a server specific user-id and a digest string (both required). 🔐

Restrictions: may only be given in the AUTHORIZATION state after the POP3 greeting

Discussion:

ok this one is SO important bestie 😭 normally every POP3 session starts with a USER/PASS exchange, which means your password gets sent in the clear on the network. for occasional use that might not be a huge deal, but lots of POP3 clients connect on a regular basis to check for new mail, and the session might start as often as every five minutes. so the chance of your password getting captured goes way up 💀

so we need another way to authenticate that gives both origin authentication and replay protection, without sending a password in the clear over the network. that's what APOP is for ✨

a POP3 server that implements APOP puts a timestamp in its banner greeting. the timestamp's syntax matches the "msg-id" in [RFC822], and it MUST be different every time the POP3 server issues a banner greeting. 🕰️ for example, on a UNIX setup where each POP3 server instance is its own UNIX process, the timestamp might look like:

<process-ID.clock@hostname>

where "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 where the POP3 server is running.

the POP3 client notes that timestamp and then sends the APOP command. the "name" parameter works exactly like the "name" parameter of the USER command 🎀 the "digest" parameter is calculated by running the MD5 algorithm [RFC1321] over a string made of the timestamp (angle-brackets included) followed by a shared secret. that shared secret is only known to the POP3 client and server, so guard it like your life depends on it 🫣 if anyone learns the secret, they can pretend to be the named user. the "digest" is a 16-octet value sent in hexadecimal format, using lower-case ASCII characters.

when the POP3 server gets the APOP command, it checks the digest. if it's correct, the server sends a positive response and the session moves into the TRANSACTION state 👑 if not, it sends a negative response and the session stays in the AUTHORIZATION state.

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 run over 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 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
LAST
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

POP3 Replies:

+OK
-ERR

ngl the only thing the server's reply really matters for is "+OK" and "-ERR", except for STAT, which is the exception 🙈 any text after that reply can be ignored by the client. 🦋

9. Example POP3 Session 🎀

this is what a whole session looks like, start to finish 🌈

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 🍓

all messages sent during a POP3 session are assumed to follow the standard for the format of Internet text messages [RFC822] 📨

heads up though: the byte count a message has on the server host can be different from the octet count assigned to it, because of local conventions for end-of-line. usually, during the AUTHORIZATION state, the POP3 client can work out each message's size in octets when it splits the maildrop into messages 🧮 for example, if the server host stores end-of-line as a single character, the server just counts each occurrence of that character as two octets.

and lines that start with the termination octet don't need to be counted twice, because the POP3 client removes all the byte-stuffed termination characters when it gets a multi-line response ✨

11. The POP and the Split-UA model 💅

okay so the big idea here is the split-UA model 🦋 the POP3 client host is basically a remote PC workstation, and it only acts as a client to the message transport system (MTS). it doesn't provide delivery or authentication services to anyone else. so it's acting as a UA (user agent) on behalf of whoever is using the workstation 💖 and the workstation uses SMTP to put mail into the MTS.

so we get two UA functions that talk to the MTS: Posting (SMTP) and Retrieval (POP3). the setup that supports this is called a split-UA, since the user agent is split across two hosts that have to work together ✨

ASIDE: Others might call this a remote-UA instead. Both names have arguments going for them 🎀

this memo explicitly uses TCP as the transport under POP3, but that doesn't have to be the case 🙈 in the MZnet split-UA, for example, the personal micro-computers don't have IP-style networking at all [MZnet]. a PC connects to the POP3 server host over a terminal connection using a simple protocol (PhoneNet). a program on the PC drives that connection and first logs in as a normal user. the login shell for this pseudo-user is a program that runs the other side of the terminal protocol and talks to one of two servers. MZnet can have several PCs, but there's only one pseudo-user login on the server host, and its user-id and password are known to every member of MZnet. so the very first thing the login shell does, after starting the terminal protocol, is demand a USER/PASS pair from the PC. that second layer of authorization is how the system figures out who is actually interacting with the MTS. the server host is considered a "trusted" MTS entity, but PCs in MZnet are not 👑 the USER/PASS pair for a PC is only known to its owner (in theory, at least) 🥺

after the client's identity is verified, a modified SMTP server starts up and the PC posts mail to the server host. once the QUIT command is given to the SMTP server and it terminates, a modified POP3 server starts and the PC retrieves mail. when the QUIT command is given to the POP3 server and it terminates, the pseudo-user's login shell ends the terminal protocol and logs the job out. then the PC closes the terminal connection to the server host 🧚

the SMTP server used by MZnet is modified because it knows it's talking to a user agent, not a "trusted" entity in the MTS. so it does perform the validation activities that an MTS entity normally performs when it accepts a message from a UA 💅

the POP3 server used by MZnet is modified too: it does not require a USER/PASS combination before entering the TRANSACTION state. why? because the PC already identified itself during that second-level authorization step ✨

NOTE: Truth in advertising laws require that the author of this memo say MZnet has not actually been fully implemented 😭 the concepts the project presented and proved led to the notion of the MZnet split-slot model. that notion inspired the split-UA concept described here, got the author interested in the POP, and heavily influenced how POP3 is described in this memo.

in fact, some UAs on the Internet already post directly to an SMTP server and retrieve mail directly from a POP3 server, even when the POP3 server and client live on the same host! 🤯

ASIDE: this raises an issue this memo purposely avoids: how does SMTP know that it's talking to a "trusted" MTS entity? 🙈

12. References 📚

[MZnet]   Stefferud, E., Sweet, J., and T. Domae, "MZnet: Mail
          Service for Personal Micro-Computer Systems,:
          Proceedings, IFIP 6.5 International Conference on
          Computer Message Systems, Nottingham, U.K., May 1984.

[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", MIT
          Laboratory for Computer Science, April 1992.

13. Security Considerations 🔐

okay this section is short but it is IMPORTANT, bestie 😭🚨 it is conjectured that using the APOP command gives you origin identification and replay protection for a POP3 session. so, 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 PASS or APOP is allowed, but never both 🙅‍♀️

otherwise, security issues are not discussed in this memo. (yes, we're aware. it's giving "not my problem, not today" 💀)

14. Acknowledgements 🫶

the POP family has a long and checkered history 🌈 although POP3 is primarily a minor revision of [RFC1225], it's based on the ideas presented in RFCs 918, 937, and 1081. literally generations of ideas went into this 👑

and a big shoutout to Alfred Grimstad, Keith McCloghrie, and Neil Ostroff, who gave significant comments on the APOP command 💖✨

15. Author's Address 🎀

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

Phone: +1 415 968 1052
Fax:   +1 415 968 2510

EMail: mrose@dbc.mtview.ca.us
X.500: rose, dbc, us