RFC 1225

Post Office Protocol: Version 3

📅 published May 1991, from ietf

Post Office Protocol - Version 3 🎀

okay bestie, this is RFC 1225 and it's giving "how do I check my mail when my computer isn't always online" 💌

Written by M. Rose of Performance Systems International 💅, and published in May 1991 🌸. It's an IAB standards track protocol, and it obsoletes RFC 1081 🧚. The header doesn't list any RFC that it updates, just the one it replaces ✨.

Status of This Memo 📋

So the vibe is: a simple way for workstations to grab mail from a mailbox server whenever they need to 📬. This RFC is an IAB standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 🫶. For the standardization state and status, check the current "IAB Official Protocol Standards" 🔥. Distribution of this memo is unlimited 🌈.

Overview 🦋

This memo is a republication of RFC 1081, which was based on RFC 918 (since revised as RFC 937) 📚. It's similar in form to the original Post Office Protocol (POP) that was proposed for the Internet community, but the protocol here is similar in spirit to the ideas that the MZnet project at the University of California, Irvine, was exploring 🍓.

Also, a lot of work went into looking at POP in a PC-based environment 💻. That work added extra functionality to this protocol and was done by the ACIS Networking Systems Group at Stanford University 🎓. The author is super grateful for their interest 🥹💜.

Introduction ✨

Some smaller nodes on the Internet can't realistically keep a message transport system (MTS) running 😩. A workstation might not have enough resources (cycles, disk space) to keep an SMTP server and its local mail delivery system resident and running all the time 🥲. It can also be expensive, or even impossible, to keep a personal computer connected to an IP-style network for long stretches (the node is missing the thing we call "connectivity") 📉.

Even so, managing mail on these smaller nodes is really useful, and they often run a user agent (UA) to help with mail handling 💖. To fix this, a node that can run 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, a "client host" is any host using the POP3 service, and a "server host" is any host offering it 🎀.

A Short Digression 🌸

This memo doesn't say how a client host puts 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 wants to put a message into the transport system, it opens 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 you do it this way, the client host acts like a user agent to the MTS, and it should NOT be treated as a "trusted" MTS entity in any sense whatsoever 🚨. We'll talk more about this idea, and about POP3's role in a split-UA model, later in the memo 🦋.

Here's the flow. 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 to the server host 💅. Once the connection is up, the POP3 server sends a greeting ✨. After that, the client and the POP3 server take turns sending commands and responses until the connection is closed or aborted 💬.

Commands in POP3 are a keyword, maybe followed by an argument, and every command ends with a CRLF pair 🍓. Responses are a success indicator, then a keyword, maybe followed by extra info, and every response also ends with a CRLF pair 🫶. There are two success indicators: positive (+OK) and negative (-ERR) 💖.

Some responses are multi-line, and the memo makes that clear wherever it applies 📚. For those, the server sends the first line and a CRLF, then any extra lines, each ending with a CRLF pair 🌈. When every line has been sent, the server sends one last line: a termination octet (decimal code 046, .) followed by a CRLF pair 🎀. If any line in a multi-line response starts with the termination octet, the server "byte-stuffs" that line by adding another termination octet in front of it 🧚.

So a multi-line response always ends with the five octets CRLF.CRLF 🦋. When the client reads a multi-line response, it checks whether each line starts with the termination octet 👀. If it does, and octets other than CRLF come after it, the client strips off the first octet of the line (the termination octet) 🫧. If it does, and a CRLF comes right after the termination character, the response from the POP server is over, and that .CRLF line doesn't count 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 POP3 server has sent its greeting, the session enters the AUTHORIZATION state 🔐. In this state, the client must identify itself to the POP3 server 🪪. Once that works, the server grabs the resources tied to the client's maildrop, and the session enters the TRANSACTION state 🎉. In this state the client asks the POP3 server to do things ✨. When the client is done, the session enters the UPDATE state 👋. Here the POP3 server releases any resources it grabbed during TRANSACTION and says goodbye 🥲. Then the TCP connection closes 🫶.

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 dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)

Notice that this greeting is a POP3 reply 🧚. The POP3 server should always give a positive response as the greeting 💖.

Now the session is in the AUTHORIZATION state 🔐. The client has to send the USER command next ✨. If the server answers USER with a positive success indicator (+OK), the client can send either the PASS command to finish authorizing, or the QUIT command to end the session 💅. If the server answers USER with a negative success indicator (-ERR), the client can either send a new USER command or send QUIT 🙈.

When the client sends PASS, the POP3 server uses the USER and PASS argument pair to decide whether the client should get access to the right maildrop 🔑. If it should, the server then grabs an exclusive-access lock on the maildrop 🔒. If the lock works, the server parses the maildrop into individual messages (see the note below) 📬, figures out the last message in the maildrop that was referenced by the RETR command 🕵️‍♀️, and sends a positive success indicator 🎉. The session now enters the TRANSACTION state 🦋. If the lock can't be grabbed, if the client is denied access to the right maildrop, or if the maildrop can't be parsed for some reason, the server sends a negative success indicator 🚫. (If the server grabbed a lock but still plans to send a negative success indicator, it must release the lock before rejecting the command 🔓.) At this point, the client can either send a new USER command and start over, or send QUIT 💜.

NOTE: Minimal POP3 implementations only need to be able to split a maildrop into its component messages 🍰. They need NOT be able to parse individual messages 🙅‍♀️. More advanced implementations may want that capability, for reasons we'll cover later 🧠.

After the POP3 server has split the maildrop into messages, it gives each message a message-id and notes its size in octets 🔢. The first message 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 (decimal) 💅.

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

Here are summaries of the three POP3 commands we've covered so far 📝:

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

The TRANSACTION State ✨

okay bestie, once the client has successfully identified itself to the POP3 server and the server has locked and burst 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 🔁. after every 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 POP3 server sends a positive response with a line holding info about the maildrop 📬. this line is called a "drop listing" for that maildrop.

all POP3 servers are required to use a certain format for drop listings so parsing stays simple 🧩. the first octets present must indicate the number of messages in the maildrop. right after that comes the size of the maildrop in octets. this memo makes no requirement on what follows the maildrop size. minimal implementations should just end that line of the response with a CRLF pair. more advanced implementations may include other information.

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

note that 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 POP3 server sends a positive response, that response has a line with info for that message. this line is called a "scan listing" for that message 🔍.

if no argument was given and the POP3 server sends a positive response, the response is multi-line 📜. after the initial +OK, the POP3 server sends one line for each message in the maildrop. each of those lines is a "scan listing" for that message.

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. right after the message-id comes the size of the message in octets. this memo makes no requirement on what follows the message size in the scan listing. minimal implementations should just end that line of the response with a CRLF pair. more advanced implementations may include other information, 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. 🙈

note that messages marked as deleted are not listed 🙅‍♀️.

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 POP3 server sends a positive response, that response is multi-line 📖. after the initial +OK, the POP3 server sends the message that matches the given message-id. it is careful to byte-stuff the termination character, just like it does for all multi-line responses 🧵.

if the number tied to this message is higher than the "highest number accessed" in the maildrop, the POP3 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 POP3 server marks the message as deleted 🗑️. any future reference to the message-id tied to that message, in any POP3 command, generates an error ❌. the POP3 server does not actually delete the message until the POP3 session enters the UPDATE state. so it's not gone yet, just marked 👻.

if the number tied to this message is higher than the "highest number accessed" in the maildrop, the POP3 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 POP3 server does nothing. it just replies with a positive response 😌. literally a vibe check 🧘‍♀️.

Possible Responses:

  • +OK

Examples:

C:    NOOP
S:    +OK

LAST

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

Discussion:

the POP3 server sends a positive response with a line holding the highest message number which accessed 🏆. zero is returned if no message in the maildrop has been accessed during previous transactions. after that, the client can infer that messages numbered higher than the LAST response are messages it has not 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 1

RSET

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

Discussion:

if any messages have been marked as deleted by the POP3 server, they get unmarked 🔄. the POP3 server then replies with a positive response. on top of that, the "highest number accessed" is reset to the value determined at the beginning of the POP3 session 💖. a total glow-up reset 🌸.

Possible Responses:

  • +OK

Examples:

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

The UPDATE State 🌙

when the client issues the QUIT command from the TRANSACTION state, the POP3 session enters the UPDATE state 🎬. (quick side note bestie: if the client issues QUIT from the AUTHORIZATION state, the POP3 session terminates but does NOT enter the UPDATE state 🙅‍♀️.)

QUIT

  • Arguments: none
  • Restrictions: none

Discussion:

the POP3 server removes all messages marked as deleted from the maildrop 🧹. then it releases the exclusive-access lock on the maildrop and replies about whether those operations worked 🔓. after that, the TCP connection is 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)

Optional POP3 Commands ✨

okay so the commands we've already covered are the ones every minimal POP3 server must support 💅 but these optional ones give the POP3 client way more freedom in handling messages while the server stays simple 🧚

🔥 NOTE: This memo STRONGLY encourages implementations to support these commands instead of building augmented drop and scan listings. Honestly the whole philosophy here is to put the smarts in the POP3 client and NOT in the POP3 server. Main character energy for the client 👑

TOP msg n

  • Arguments: a message-id (required) and a number. The message-id may NOT refer to a message marked as deleted 🙈
  • Restrictions: only in the TRANSACTION state 🦋
  • Discussion: if the server says yes (positive response), the reply is multi-line 🌸 After the initial +OK, the server sends the message headers, then the blank line that separates the headers from the body, then the number of body lines that were asked for. It has to byte-stuff the termination character, same as every other multi-line response 💖

If the number of lines the client asks for is bigger than how many lines the body actually has, the server just sends the entire message ✨

  • 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

RPOP user

  • Arguments: a client specific user-id (required) 🎀
  • Restrictions: only in the AUTHORIZATION state, and only after a successful USER command. On top of that, it only works if the client connected from a reserved (privileged) TCP port 👑
  • Discussion:

The RPOP command can be used instead of PASS to authenticate access to the maildrop 🔐 For it to work, the POP3 client has to connect from a reserved TCP port (port < 1024) to the server. The server looks at the argument pair from the USER and RPOP commands to decide whether the client gets access to the right maildrop.

The big difference from PASS is that the server checks whether the remote user named in RPOP, who lives on the POP3 client host, is allowed to access the maildrop of the user named in USER. (On Berkeley UNIX, that's the .rhosts mechanism, lowkey iconic 🧚) Apart from this different way of authenticating, the command works exactly like PASS 🍓

⚠️ Security note, and this one is serious bestie 😭 The use of this feature has let a LOT more people get into numerous hosts on local networks (and sometimes remote networks) 💀 Those people got in by guessing passwords or otherwise breaking into the system. Please don't treat this lightly 🫶
  • Possible Responses:
    • +OK maildrop locked and ready
    • -ERR permission denied
  • Examples:
C:    USER mrose
S:    +OK mrose is a real hoopy frood
C:    RPOP mrose
S:    +OK mrose's maildrop has 2 messages (320
      octets)

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

RPOP user               valid in the AUTHORIZATION state

TOP msg n               valid in the TRANSACTION state

POP3 Replies

+OK
-ERR

Here's the tea 🍵 apart from the STAT command, the only thing the client needs to look at in a reply to any command is "+OK" or "-ERR". Whatever text comes after that can be ignored by the client, so don't stress about it 💅

Example POP3 Session 🎀

    S: <wait for connection on TCP port 110>
        ...
    C: <open connection>
    S:    +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
    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:    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>

Message Format 💌

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

Okay, this part is important 🤓 the byte count a message has on the server host can be different from the octet count given to that message, because of local conventions for end-of-line. Usually, during the AUTHORIZATION state, the POP3 client can work out the size of each message in octets when it splits the maildrop into messages 🧮 For example, if the server host stores end-of-line as one 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, since the POP3 client removes all the byte-stuffed termination characters when it gets a multi-line response 🫶

The POP and the Split-UA model 🌈

The big idea behind POP3 is the split-UA model 🦋 The POP3 client host is a remote, PC-based workstation, and it acts purely as a client to the message transport system. It doesn't provide delivery or authentication services to anyone else. So it's acting as a UA on behalf of the person using the workstation. On top of that, the workstation uses SMTP to put mail into the MTS 💅

So we've got two UA functions that talk to the message transport system: Posting (SMTP) and Retrieval (POP3). The entity that supports this kind of setup is called a split-UA, because the user agent is split between two hosts that have to work together to do these functions 🧚

🌸 ASIDE: Others might call this a remote-UA instead. There are arguments for both terms.

This memo explicitly references TCP as the transport for POP3, but it doesn't have to be TCP 🙈 Take the MZnet split-UA: the personal micro-computers there don't have IP-style networking. To reach the POP3 server host, a PC sets up a terminal connection using a simple protocol (PhoneNet) 📟 A program on the PC drives that connection and first starts a login session as a normal user. The login shell for this pseudo-user is a program that drives the other end of the terminal protocol and talks to one of two servers 🍓

MZnet can support several PCs, but there's only one pseudo-user login on the server host, and its user-id and password are known to all members of MZnet. So the very first thing the login shell does, after starting the terminal protocol, is demand a USER/PASS authorization pair from the PC. This second level of authorization is there to figure out who's actually interacting with the MTS. The server host counts as a "trusted" MTS entity, but the PCs in MZnet don't. And the USER/PASS pair for a PC is only known to its owner (in theory, at least) 🤞

Once the identity of the client is verified, a modified SMTP server starts up and the PC posts mail to the server host. After the QUIT command is given to the SMTP server and it shuts down, a modified POP3 server starts and the PC retrieves its mail. After QUIT goes to the POP3 server and it terminates, the login shell for the pseudo-user 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 so it knows it's talking to a user agent, not a "trusted" entity in the message transport system. So when it accepts a message from a UA, it does the validation work that an MTS entity normally does 🔍

The POP3 server used by MZnet is modified too. It doesn't require a USER/PASS combination before entering the TRANSACTION state, because the PC already identified itself in the second-level authorization step described above 💖

🎀 NOTE: Truth in advertising laws mean the author of this memo has to say that 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 in this memo, led to the author's interest in POP, and heavily shaped how POP3 is described here.

Honestly though, some UAs on the Internet already post directly to an SMTP server and retrieve directly from a POP server, even when the POP server and client are on the same host! 🤯✨

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

References 📚✨

Okay bestie, here's every source I've been name-dropping, all in one place 🎀

  • [MZnet] Stefferud, E., J. Sweet, 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", USC/Information Sciences Institute, August 1982.
  • [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text Messages", University of Delaware, August 1982.
  • [RFC937] Butler, M., J. Postel, D. Chase, J. Goldberger, and J. Reynolds, "Post Office Protocol - Version 2", RFC 937, USC/Information Sciences Institute, February 1985.
  • [RFC1060] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990.

Security Considerations 🔒

Okay so, real talk: security issues are not discussed in this memo 💀 No notes on that one, bestie. Not me being unbothered about it, just what the doc says 🙈

Author's Address 💌

This is the queen who wrote it, Marshall T. Rose 👑 Here's how to reach them 🧚

   Marshall T. Rose
   Performance Systems International
   5201 Great America Parkway
   Suite 3106
   Santa Clara, CA  95054

   Phone: +1 408 562 6222

   EMail: mrose@psi.com
   X.500:  rose, psi, us
📦 where this page comes from