RFC 1939

Post Office Protocol - Version 3

📅 published May 1996, from ietf

RFC 1939: Post Office Protocol - Version 3 💌 (part 1 of 4)

okay bestie, this is RFC 1939, called "Post Office Protocol - Version 3" 💌 It's from the Network Working Group, it's STD 53, it's on the Standards Track, and it's dated May 1996. J. Myers (Carnegie Mellon) and M. Rose (Dover Beach Consulting, Inc.) wrote it 🎀 It also obsoletes RFC 1725, so this one officially takes over from that doc ✨

Status of This Memo 🎀

this document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. for the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited 📜

Table of Contents 🧚

   1. Introduction ................................................    2
   2. A Short Digression ..........................................    2
   3. Basic Operation .............................................    3
   4. The AUTHORIZATION State .....................................    4
      QUIT Command ................................................    5
   5. The TRANSACTION State .......................................    5
      STAT Command ................................................    6
      LIST Command ................................................    6
      RETR Command ................................................    8
      DELE Command ................................................    8
      NOOP Command ................................................    9
      RSET Command ................................................    9
   6. The UPDATE State ............................................   10
      QUIT Command ................................................   10
   7. Optional POP3 Commands ......................................   11
      TOP Command .................................................   11
      UIDL Command ................................................   12
      USER Command ................................................   13
      PASS Command ................................................   14
      APOP Command ................................................   15
   8. Scaling and Operational Considerations ......................   16
   9. POP3 Command Summary ........................................   18
   10. Example POP3 Session .......................................   19
   11. Message Format .............................................   19
   12. References .................................................   20
   13. Security Considerations ....................................   20
   14. Acknowledgements ...........................................   20
   15. Authors' Addresses .........................................   21
   Appendix A. Differences from RFC 1725 ..........................   22
   Appendix B. Command Index ......................................   23

1. Introduction ✨

okay so picture this 🧚 some smaller nodes on the Internet just can't keep a whole message transport system (MTS) running. like, 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. and it can be expensive (or straight up impossible) to keep a personal computer hooked up to an IP-style network for long stretches, because the node is missing the thing called "connectivity" 💀

still, managing mail on these smaller nodes is SO useful, and they usually 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 POP3 is how a workstation grabs the mail the server is holding for it 📬

POP3 is not meant to do heavy manipulation of mail on the server. normally, mail gets downloaded and then deleted 🧹 A more advanced (and complex) protocol, IMAP4, is discussed in [RFC1730].

for the rest of this memo, "client host" means a host using the POP3 service, and "server host" means a host offering the POP3 service 🦋

2. A Short Digression 🌸

this memo does not specify how a client host gets mail into the transport system. but here's a method that fits the philosophy of this memo:

when the UA on a client host wants to put a message into the transport system, it opens an SMTP connection to its relay host and sends all its mail there. that relay host could be the POP3 server host for the client host, but it doesn't have to be. and ofc the relay host has to accept mail for delivery to arbitrary recipient addresses. that ability isn't required of all SMTP servers 💅

3. Basic Operation 🎀

so 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 that connection is up, the POP3 server sends a greeting, and then the client and the POP3 server trade commands and responses (respectively) until the connection gets closed or aborted 🤝

POP3 commands are a case-insensitive keyword, maybe 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 by a single SPACE character. keywords are three or four characters long, and each argument can be up to 40 characters long ✨

responses are a status indicator and a keyword, maybe with extra info after that. every response ends with a CRLF pair, and it can be up to 512 characters long, including the terminating CRLF. there are currently two status indicators: positive ("+OK") and negative ("-ERR"). servers MUST send the "+OK" and "-ERR" in upper case 🔥

some responses are multi-line, and the memo makes it clear which ones 👀 for those, after the first line and a CRLF, the extra lines come next, and each one ends with a CRLF pair. when everything has been sent, a final line goes out: a termination octet (decimal code 046, ".") and a CRLF pair. if any line of a multi-line response starts with the termination octet, that line gets "byte-stuffed" by pre-pending the termination octet to it. so a multi-line response ends with the five octets CRLF.CRLF 🧠

when a client reads a multi-line response, it checks whether each line starts with the termination octet. if it does and octets other than CRLF follow, the first octet (the termination octet) gets stripped away. if it does and 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 lifetime. once the TCP connection is open and the POP3 server has sent the greeting, the session enters the AUTHORIZATION state. here the client must identify itself to the POP3 server. once the client has done that successfully, the server grabs the resources tied to the client's maildrop, and the session enters the TRANSACTION state, where the client requests actions from the POP3 server. when the client issues the QUIT command, the session enters the UPDATE state. there, the POP3 server releases any resources it grabbed during TRANSACTION and says goodbye. then the TCP connection gets closed 👑

a server MUST respond to an unrecognized, unimplemented, or syntactically invalid command with a negative status indicator. a server MUST also respond to a command issued while the session is in an incorrect state with a negative status indicator 🙃 there's no general method for a client to tell apart a server that doesn't implement an optional command from a server that's unwilling or unable to process it.

a POP3 server MAY have an inactivity autologout timer. if it does, that timer MUST be at least 10 minutes' duration. any command from the client during that interval should be enough to reset the autologout 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 the TCP connection has been opened by a POP3 client, the POP3 server issues a one-line greeting. it can be any positive response. an example might be:

      S:  +OK POP3 server ready

the POP3 session is now in the AUTHORIZATION state. the client must identify and authenticate itself to the POP3 server. two possible mechanisms for doing this are described in this document: the USER and PASS command combination, and the APOP command. both get described later in this document. more authentication mechanisms are described in [RFC1734]. there's no single authentication mechanism that every POP3 server is required to have, but a POP3 server must of course support at least one authentication mechanism 🔐

once the POP3 server has determined, through any authentication command, that the client should get access to the right maildrop, it acquires an exclusive-access lock on that maildrop, as necessary to stop messages from being modified or removed before the session enters the UPDATE state. if the lock is acquired successfully, the POP3 server responds with a positive status indicator. the POP3 session now enters the TRANSACTION state, with no messages marked as deleted 🔒

if the maildrop can't be opened for some reason (like a lock can't be acquired, the client is denied access to the maildrop, or the maildrop can't be parsed), the POP3 server responds with 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 returning a negative status indicator, the server may close the connection. if the server doesn't close the connection, the client may either issue a new authentication command and start again, or it may issue the QUIT command 🙈

after the POP3 server has opened the maildrop, it assigns a message-number to each message and notes the size of each message in octets. the first message in the maildrop gets a message-number of "1", the second gets "2", and so on, so the nth message in a maildrop gets a message-number of "n". in POP3 commands and responses, all message-numbers and message sizes are expressed in base-10 (aka decimal) 🔢

here's the summary for the QUIT command when it's used in the AUTHORIZATION state:

QUIT Command 👋

      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 over and over, and the server replies to each one 🫶. eventually the client sends QUIT and the session moves on to 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 back a positive response with one line of info about the maildrop. that line is called a "drop listing" for that maildrop 📋.

to make parsing easy, every POP3 server has to use one specific format for drop listings 🤓. the positive response is +OK, then a single space, then the number of messages in the maildrop, then another single space, then the size of the maildrop in octets. this memo doesn't put any rules on what comes after the maildrop size. minimal implementations just end that line with a CRLF pair. fancier implementations can add other info if they want.

🚨 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 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

Discussion: if an argument was given and the server sends a positive response, that response has one line with info for that message. that 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 for each message in the maildrop. if there are no messages in the maildrop, the server sends no scan listings at all. instead it sends a positive response followed by a line containing the termination octet and a CRLF pair ✨.

again, to keep parsing simple, all POP3 servers are required to use a certain format for scan listings. a scan listing is the message-number of the message, then a single space, then the exact size of the message in octets. ways to calculate that exact size are described in the "Message Format" section below. this memo doesn't put any rules on what comes after the message size in the scan listing. minimal implementations just end that line with a CRLF pair. fancier 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 which permit the client to parse the messages in the maildrop.

btw, 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

Discussion: if the server sends a positive response, then the response is multi-line 📬. after the initial +OK, the server sends the message that matches the given message-number. it has to be careful to byte-stuff the termination character, the same way it does for all multi-line responses 🧠.

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

Discussion: the server marks the message as deleted 🚩. any future reference to that message's message-number in a POP3 command gives an error, so it's basically ghosted 👻. the server does not actually delete the message until the session enters the UPDATE state.

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

Possible Responses: +OK

Examples:

C: NOOP
S: +OK

RSET 🔄

Arguments: none

Restrictions: may only be given in the TRANSACTION state

Discussion: if the server has marked any messages as deleted, those marks get undone 🪄. then the server replies with a positive response. main character reset energy 💅.

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 🎉. (btw, if the client issues QUIT from the AUTHORIZATION state, the session terminates but does NOT enter the UPDATE state 🙅‍♀️.)

if a session terminates for some reason other than a client-issued QUIT command, the session does NOT enter the UPDATE state and MUST not remove any messages from the maildrop 🛑. no cap, that one is serious.

QUIT 👋

Arguments: none

Restrictions: none

Discussion: the server removes all messages marked as deleted from the maildrop and replies with the status of that operation 📮. if there's an error while removing messages, like a resource shortage, the maildrop may end up with some or none of the messages marked as deleted actually removed 😬. in no case may the server remove any message that isn't marked as deleted.

whether the removal worked or not, the server then releases any exclusive-access lock on the maildrop and closes the TCP connection 💜.

Possible Responses:

  • +OK
  • -ERR some deleted messages not removed

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 bestie, so the POP3 commands we already covered must be supported by all minimal POP3 server implementations 💅 no cap, that's the baseline.

these optional commands are the fun part 🎀 they give the POP3 client way more freedom in message handling, and the server stays simple. iconic.

NOTE: this memo STRONGLY encourages implementations to support these commands instead of building augmented drop and scan listings 🫶 the whole philosophy here is to put the intelligence in the POP3 client and not the POP3 server. main character energy for the client 👑

TOP msg n

Arguments: a message-number (required) which may NOT refer to a message marked as deleted, and a non-negative number of lines (required) 🙈

Restrictions: may only be given in the TRANSACTION state

Discussion: if the POP3 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 the number of lines of the body you asked for. the server has to be careful to byte-stuff the termination character, same as with all multi-line responses.

ngl this is so smart: 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 ✨

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 (optional), which, if present, may NOT refer to a message marked as deleted 🦋

Restrictions: may only be given in the TRANSACTION state.

Discussion: if you give an argument and the POP3 server says yes (positive response), the server replies with one line that has info for that message. this line is called a "unique-id listing" for that message 🧚

if you don't give an argument and the server says yes, the reply is multi-line 🌸 after the initial +OK, the server sends one line for every message in the maildrop, each one with info for that message. again, that's a "unique-id listing" 💅

here's the part that keeps parsing easy: all POP3 servers are required to use one specific format for unique-id listings. each listing is the message-number of the message, then a single space, then the unique-id of the message. nothing comes after the unique-id 🍓

the unique-id is an arbitrary string the server picks itself. it's one to 70 characters, all in the range 0x21 to 0x7E, and it uniquely identifies a message inside a maildrop. it also persists across sessions 🔥 that persistence is required even if a session ends without entering the UPDATE state. the server should never reuse a unique-id in a given maildrop, for as long as the entity using that unique-id exists 🙈

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

it's generally better for servers to store arbitrarily assigned unique-ids in the maildrop, but this spec also lets unique-ids be calculated as a hash of the message 🌈 that means clients should be able to handle the case where two identical copies of a message in a maildrop have the same unique-id. no drama, just be prepared 🫶

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

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

Discussion: to authenticate with the USER and PASS combo, the client must first issue the USER command ✨ if the server says +OK, the client may then issue PASS to finish authenticating, or QUIT to end the session. if the server says -ERR to USER, the client may either try a new authentication command or issue QUIT 🎀

the server may return a positive response even if no such mailbox exists 👀 it may return a negative response if the mailbox does exist but doesn't allow plaintext password authentication 🙅‍♀️

Possible Responses:

  • +OK name is a valid mailbox
  • -ERR never heard of mailbox name

Examples:

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

PASS string

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

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

Discussion: when the client issues PASS, the POP3 server uses the argument pair from the USER and PASS commands to decide whether the client gets access to the right maildrop 🦋

since PASS has exactly one argument, a POP3 server may treat spaces in the argument as part of the password, instead of as argument separators. wild, but valid 💅

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: -ERR maildrop already locked
  ...
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: +OK mrose's maildrop has 2 messages (320 octets)

APOP name digest

Arguments: a string identifying a mailbox and a MD5 digest string (both required) 🧁

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

Discussion: normally every POP3 session starts with a USER/PASS exchange, which sends a server/user-id specific password in the clear on the network 😬 for occasional use, that might not be a huge risk. but lots of POP3 clients connect to the server on a regular basis to check for new mail, and the interval between sessions can be on the order of five minutes. so the risk of password capture gets way, way higher 🚨

we need an alternate method that gives both origin authentication and replay protection, without sending a password in the clear over the network. that's exactly what APOP is for 💖

a POP3 server that implements APOP includes a timestamp in its banner greeting. the syntax of the timestamp corresponds to the msg-id in [RFC822], and it MUST be different each time the POP3 server issues a banner greeting 🔥

for example, on a UNIX implementation where a separate UNIX process is used for each instance of a POP3 server, the timestamp might look like this:

<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 this timestamp, then issues the APOP command 🦋 the name parameter works exactly like the name parameter of the USER command. the digest parameter is calculated by applying the MD5 algorithm [RFC1321] to a string made of the timestamp (angle-brackets included) followed by a shared secret. this shared secret is a string known only to the POP3 client and server 🤫

great care should be taken to stop unauthorized disclosure of the secret, because if someone knows it, they can masquerade as the named user 😱 the digest parameter 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 the digest is correct, the server issues a positive response and the POP3 session enters the TRANSACTION state 🎉 otherwise, a negative response is issued and the session stays in the AUTHORIZATION state 💀

note that as the shared secret gets longer, it gets harder to derive. so shared secrets should be long strings, considerably 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 tan-staaf. so the MD5 algorithm is applied to this string:

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

which produces a digest value of:

c4c9334bac560ecc979e58001b3e22fb

8. Scaling and Operational Considerations ✨

Okay so, once some of the optional features got added to POP3, people started using them in huge commercial post office operations where most of the users have nothing to do with each other 🏢. In those setups (and some others too), users and vendors of POP3 clients figured out that combining the UIDL command with not issuing the DELE command gives you a weak version of the "maildrop as semi-permanent repository" thing that's normally an IMAP move 🦋. Of course, the other IMAP capabilities, like polling an existing connection for newly arrived messages and supporting multiple folders on the server, are not present in POP3 🙃.

When casual users do this, already-read messages tend to pile up on the server without bound 📦. That is clearly an undesirable behavior pattern from the standpoint of the server operator 😬. It gets worse because POP3's limited capabilities don't allow efficient handling of maildrops with hundreds or thousands of messages 💀.

So, it is recommended that operators of large-scale multi-user servers, especially ones where the user's only access to the maildrop is via POP3, consider options like:

  • Imposing a per-user maildrop storage quota or the like. 💾

A disadvantage to this option is that accumulation of messages may result in the user's inability to receive new ones into the maildrop. Sites which choose this option should be sure to inform users of impending or current exhaustion of quota, perhaps by inserting an appropriate message into the user's maildrop.

  • Enforce a site policy regarding mail retention on the server. 🗂️

Sites are free to establish local policy regarding the storage and retention of messages on the server, both read and unread. For example, a site might delete unread messages from the server after 60 days and delete read messages after 7 days. Such message deletions are outside the scope of the POP3 protocol and are not considered a protocol violation.

Server operators enforcing message deletion policies should take care to make all users aware of the policies in force.

Clients must not assume that a site policy will automate message deletions, and should continue to explicitly delete messages using the DELE command when appropriate.

It should be noted that enforcing site message deletion policies may be confusing to the user community, since their POP3 client may contain configuration options to leave mail on the server which will not in fact be supported by the server.

One special case of a site policy is that messages may only be downloaded once from the server, and are deleted after this has been accomplished. This could be implemented in POP3 server software by the following mechanism: "following a POP3 login by a client which was ended by a QUIT, delete all messages downloaded during the session with the RETR command". It is important not to delete messages in the event of abnormal connection termination (ie, if no QUIT was received from the client) because the client may not have successfully received or stored the messages. Servers implementing a download-and-delete policy may also wish to disable or limit the optional TOP command, since it could be used as an alternate mechanism to download entire messages. 🔥

9. POP3 Command Summary 💅

      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

      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 with the exception of the STAT, LIST, and UIDL commands, the reply given by the POP3 server to any command is significant only to "+OK" and "-ERR". Any text occurring after this reply may be ignored by the client. 🧠

10. Example POP3 Session 🧚

      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>

11. Message Format 💌

All messages transmitted during a POP3 session are assumed to conform to the standard for the format of Internet text messages [RFC822].

It is important to note that the octet count for a message on the server host may differ from the octet count assigned to that message due to local conventions for designating end-of-line. Usually, during the AUTHORIZATION state of the POP3 session, the POP3 server can calculate the size of each message in octets when it opens the maildrop. For example, if the POP3 server host internally represents end-of-line as a single character, then the POP3 server simply counts each occurrence of this character in a message as two octets. Note that lines in the message which start with the termination octet need not (and must not) be counted twice, since the POP3 client will remove all byte-stuffed termination characters when it receives a multi-line response. 🤓

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

[RFC1730] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 1730, University of Washington, December 1994.

[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994.

13. Security Considerations 🚨

It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands should not allow both methods of access for a given user; that is, for a given mailbox name, either the USER/PASS command sequence or the APOP command is allowed, but not both.

Further, note that as the length of the shared secret increases, so does the difficulty of deriving it. 🔐

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

Use of the PASS command sends passwords in the clear over the network. 😭
Use of the RETR and TOP commands sends mail in the clear over the network. 😭

Otherwise, security issues are not discussed in this memo.

14. Acknowledgements 🫶

The POP family has a long and checkered history. Although primarily a minor revision to RFC 1460, POP3 is based on the ideas presented in RFCs 918, 937, and 1081.

In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff provided significant comments on the APOP command. 👑

15. Authors' Addresses 🎀

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

Appendix A. Differences from RFC 1725 ✨

This memo is a revision to RFC 1725, a Draft Standard. It makes the following changes from that document:

  • clarifies that command keywords are case insensitive.
  • specifies that servers must send "+OK" and "-ERR" in upper case.
  • specifies that the initial greeting is a positive response, instead of any string which should be a positive response.
  • clarifies behavior for unimplemented commands.
  • makes the USER and PASS commands optional.
  • clarified the set of possible responses to the USER command.
  • reverses the order of the examples in the USER and PASS commands, to reduce confusion.
  • clarifies that the PASS command may only be given immediately after a successful USER command.
  • clarified the persistence requirements of UIDs and added some implementation notes.
  • specifies a UID length limitation of one to 70 octets.
  • specifies a status indicator length limitation of 512 octets, including the CRLF.
  • clarifies that LIST with no arguments on an empty mailbox returns success.
  • adds a reference from the LIST command to the Message Format section
  • clarifies the behavior of QUIT upon failure
  • clarifies the security section to not imply the use of the USER command with the APOP command.
  • adds references to RFCs 1730 and 1734
  • clarifies the method by which a UA may enter mail into the transport system.
  • clarifies that the second argument to the TOP command is a number of lines.
  • changes the suggestion in the Security Considerations section for a server to not accept both PASS and APOP for a given user from a "must" to a "should".
  • adds a section on scaling and operational considerations

Appendix B. Command Index 📖

       APOP .......................................................   15
       DELE .......................................................    8
       LIST .......................................................    6
       NOOP .......................................................    9
       PASS .......................................................   14
       QUIT .......................................................    5
       QUIT .......................................................   10
       RETR .......................................................    8
       RSET .......................................................    9
       STAT .......................................................    6
       TOP ........................................................   11
       UIDL .......................................................   12
       USER .......................................................   13
📦 where this page comes from