RFC 937
Post Office Protocol: Version 2
POST OFFICE PROTOCOL - VERSION 2 📬
Okay bestie, this is RFC 937 🎀 It came out in February 1985 from ISI, written by M. Butler, J. Postel, D. Chase, J. Goldberger, and J. K. Reynolds 🦋 It's a proposed protocol for the ARPA-Internet community, and it obsoletes RFC 918. This memo is a revision of RFC 918, so think of it as the glow-up version 💅
Status of this Memo
This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server 💌 It specifies a proposed protocol for the ARPA-Internet community, and it's basically asking everyone to discuss it and suggest improvements 🙏 This memo is a revision of RFC 918. Distribution of this memo is unlimited 🌸
Introduction
okay so the whole point of POP2 (Post Office Protocol Version 2) is to let a user's workstation grab mail from a mailbox server ✨ The mail is expected to get posted from the workstation to the mailbox server through the Simple Mail Transfer Protocol (SMTP). If you want the deets, check out RFC-821 [1] and RFC-822 [2] 🧚
This protocol assumes a reliable data stream, like the one TCP gives you or any similar protocol 💖 When TCP is used, the POP2 server listens on port 109 [4] 🔥
System Model and Philosophy
Here's the vibe: the workstation counts as an Internet host because it implements IP, but we do NOT expect it to hold the user's mailbox 🙅♀️ The mailbox should live on a server machine instead ☁️
We think it's really important for the mailbox to sit on an "always up" machine 💜 A workstation might get powered down a lot, or just be unavailable as an SMTP server, and that's totally normal 😴
POP2 is built for workstations and servers on a low-delay, high-throughput, local network (like Ethernets) ⚡ It might be useful in other environments too, but if things are super different there, the split of work between client and server might need to look different, and a different protocol could be required 🌈
Let's do an example 🍓 Say the user's real name is John Smith, the user's machine is called FIDO, and the mailbox server is called DOG-HOUSE. Then the user's mail should be addressed to JSmith@DOG-HOUSE.ARPA (not JSmith@FIDO.ARPA) 🐶
So the destination of the mail is the mailbox on the server machine 📭 POP2 and the workstation are just a way to look at the messages sitting in that mailbox 👀
The user isn't tied to any one workstation for checking their mail. The workstation doesn't show up anywhere in the mailbox address, so you can log in from wherever you want 🦋
This is a very simple protocol, and it is NOT a user interface 💅 We expect there to be a friendly program on the workstation that handles the user side. POP2 itself is not "user friendly", and that's on purpose 😭 It has two basic rules: "if anything goes wrong close the connection", and have few options 🫶
POP2 doesn't parse messages in any way 🙈 It doesn't analyze message headers like Date:, From:, To:, Cc:, or Subject:. It just transmits whole messages from a mailbox server to a client workstation 📨
The Protocol
The POP2 protocol is a sequence of commands and replies ✨ The design takes a lot of inspiration from earlier protocols in the ARPA-Internet community 💜
The server MUST be listening for a connection. When a connection gets opened, the server sends a greeting message and then waits for commands. When commands come in, the server acts on them and responds with replies 👑
The client opens a connection, waits for the greeting, then sends the HELO command with the user name and password arguments to establish authorization to access mailboxes 🔐 The server returns the number of messages in the default mailbox 📬
The client MAY read the default mailbox associated with the user name, or the client MAY select a different mailbox by using the FOLD command 📂 The server returns the number of messages in whichever mailbox got selected 🌷
The client starts a message reading transaction with a READ command 📖 The read command MAY optionally indicate which message number to read. If it doesn't, the default is the current message, which goes up by one whenever a message is read and gets set back to one when a new folder is selected 🔢 The server returns the number of characters in the message 🧮
The client asks for the content of the message to be sent with the RETR command, and the server sends the message data 💌
Once all the data has been received, the client sends an acknowledgment command. It's one of ACKS, ACKD, and NACK 🫧
ACKSmeans "I've received the message successfully and please keep it in the mailbox" ✅ACKDmeans "I've received the message successfully and please delete it from the mailbox" 🗑️NACKmeans "I did not receive the message and please keep it in the mailbox" ❌
With ACKS or ACKD, the server increments the current message indicator. With NACK, the current message indicator stays right where it is 🎯
In every case, the server returns the number of characters in the (now) current message 🔍
The client ends the session with the QUIT command, and the server returns an ok 👋
The Normal Scenario
Here's how a regular session goes, start to finish 🎬
Client Server
------ ------
Wait for Connection
Open Connection -->
<-- + POP2 Server Ready
Wait for Command
HELO Fred Secret -->
<-- #13 messages for you
Wait for Command
READ 13 -->
<-- =537 characters in that message
Wait for Command
RETR -->
<-- (send the message data)
Wait for Command
ACKS -->
<-- =0 no more messages
Wait for Command
QUIT -->
<-- + OK
Close connection --> <-- Close connection
Wait for Connection (go back to start)Definitions of Commands and Replies ✨
Summary of Commands and Replies 💖
Okay, bestie, here's the cheat sheet. Every command on one side, every reply on the other, all in one tidy table 🎀
Commands Replies
-------- -------
HELO user password + OK
FOLD mailbox - Error
READ [n] #xxx
RETR =yyy
ACKS
ACKD
NACK
QUITCommands 🦋
HELO user password 👑
The Hello command introduces the user to the server and carries the password that proves it's really them 🫶 The server uses this info to decide who gets into which mailboxes, so it's literally the gatekeeper energy. The Hello command is the HELO keyword, followed by the user argument, followed by the password argument, followed by CRLF.
Possible responses:
"#nnn", where nnn is the number of messages in the default mailbox,""- error report"and Close the connection. 💀
FOLD mailbox 🧚
The Folder command switches to a different mailbox or mail folder. The server must check that the user is permitted read access to this mailbox. If the mailbox is empty or doesn't exist, the number of messages reported is zero, so no drama 🌸 The Folder command is the FOLD keyword, followed by the mailbox argument, followed by CRLF.
Possible responses:
"#nnn", where nnn is the number of messages in this mailbox.
READ [nnn] 📖
The Read command starts a message reading transaction. If you give Read without an argument, the current message is implied, and the current message indicator gets bumped up by the ACKS or ACKD commands. If you do pass an argument, it's the message number you want to read, and this command sets the current message indicator to that value. The server sends back the count of characters in the message that's about to be transmitted. If there's no message to be read, a count of zero comes back. If the message was previously deleted with the ACKD command, a count of zero comes back too 🙈
The Read command is followed by the RETR command, the READ command, the FOLD command, or the QUIT command.
Do not attempt to RETR a message of zero characters. Zero means nothing's there, bestie 🚫
The Read command is the READ keyword, optionally followed by the nnn message number argument, followed by CRLF.
Possible responses:
"=ccc", where ccc is the number of characters in this message.
RETR 📨
The Retrieve command confirms that the client is ready to receive the mail data. It must be followed by an acknowledgment command. The server will close the connection if asked to transmit a message of zero characters (in other words, a message that doesn't exist) 😭 The message gets transmitted according to the Internet mail format standard RFC-822 [2] in NVT-ASCII. The Retrieve command is the RETR keyword, followed by CRLF.
Possible responses:
- the message data
- Close the connection
ACKS 💜
The Acknowledge and Save command confirms that the client has received and accepted the message. The ACKS command ends the message reading transaction. The message stays in the mailbox, and the current message indicator gets incremented. The server returns the count of characters in the now current message that's about to be transmitted. If there's no message to be read, or the message is marked deleted, a count of zero comes back. The Acknowledge and Save command is the ACKS keyword, followed by CRLF.
Possible responses:
"=ccc", where ccc is the number of characters in the next message.
ACKD 🗑️
The Acknowledge and Delete command confirms that the client has received and accepted the message. The ACKD command ends the message reading transaction. If the user is authorized to have write access to the mailbox, the message gets deleted from the mailbox. Well, technically it's only marked for deletion 👀 The actual change happens when the mailbox is released at the end of the session, or when the client picks another mailbox with the FOLD command. The messages aren't renumbered until the mailbox is released.
If the user doesn't have write access to the mailbox, no change is made to the mailbox. The response is the same whether or not the message was actually deleted, so the server isn't spilling any tea there 🍵 The current message indicator gets incremented. The server returns the count of characters in the now current message that's about to be transmitted. If there's no message to be read, or the message is marked deleted, a count of zero comes back. The Acknowledge and Delete command is the ACKD keyword, followed by CRLF.
Possible responses:
"=ccc", where ccc is the number of characters in the next message.
NACK 🙅♀️
The Negative Acknowledge command reports that the client did not receive the message. The NACK command ends the message reading transaction. The message stays in the mailbox. The current message indicator stays the same. The server returns the count of characters in the current message. Since the count being returned is for the message that was just transmitted, the message must exist and must not be marked deleted, and the count must be positive (non-zero). The Negative Acknowledge command is the NACK keyword, followed by CRLF.
Possible responses:
"=ccc", where ccc is the number of characters in this message.
QUIT 👋
The Quit command says the client is done with the session. The server sends an OK response and then closes the connection. The Quit command is the QUIT keyword, followed by CRLF.
Possible responses:
"+ OK"and Close the connection
Replies 🌈
Greeting 🎀
The greeting is sent by the server as soon as the connection is established. It's a plus sign, followed by the protocol name ("POP2"), followed by the server host name, optionally followed by text, and ending with a CRLF. First impressions matter, so this is the server's little hello 💅
+ ✅
The success or plus sign response means the operation named in the command finished successfully. It's a plus sign, optionally followed by text, ending with a CRLF. Main character energy ✨
- ❌
The failure or minus sign response means the operation named in the command failed. It's a minus sign, optionally followed by text, ending with a CRLF. Not the vibe, but at least it's clear 💀
= 📏
The length or equal sign response tells you the length in characters of the message the command referred to. It's an equal sign, followed by a number, optionally followed by text, ending with a CRLF.
# 🔢
The count or number sign response tells you how many messages are in the folder or mailbox the command referred to. It's a number sign, followed by a number, optionally followed by text, ending with a CRLF.
Timeouts ⏰
Any protocol like this has to have timeouts, no cap. Neither side wants to get stuck waiting forever for the other one, especially if the other side has gone totally unhinged or crashed 😭
The client expects a reply to a command pretty quickly, so it should have a short timeout for this. This timeout is called T1.
For some servers, it might take some processing to count the messages in a mailbox, figure out the length of a message, or reformat a stored message for transmission. So this timeout has to leave room for that processing time. Also, be careful not to time out while waiting for a RETR reply when a long message is actually still being transferred 🐢
The server expects the session to keep moving with some delay between commands, but not excessive delay. So it should have a long timeout while waiting for the next command. This timeout is T2.
One way people use this protocol is with lots of different clients that interact with the human user and the server in their own ways. Those clients still open the connection, send a sequence of commands, and close the connection, all without waiting on the human user to step in. For clients like that, it's reasonable for the server to use a fairly small value for timeout T2 🤖
On the other hand, a client could be very human-directed, with the user making decisions between each command. That would cause arbitrary delays between client commands, and the value of timeout T2 would need to be pretty large 🫠
Implementation Discussion 🛠️
Comments on a Server on TOPS-20 🖥️
On TOPS-20, a mailbox is a single file. New messages get appended to the file, and there's a separator line between messages.
The tricky part of implementing a POP2 server on TOPS-20 is handling message deletion 🫣 This only has to be done for mailboxes (files) where the user has write access. The challenge is avoiding two problems: (1) keeping other users from accessing or updating the mailbox for long stretches, and (2) accidentally deleting a message the user hasn't seen yet.
One suggestion goes like this:
When a mailbox is first selected, if the user has write access, rename the mailbox file to some temporary name. That way, new messages get placed in a new instance of the mailbox file. Conduct all POP2 operations on the temporary mailbox file (including deleting messages). When the POP2 session is over or another mailbox is selected, prepend any messages left undeleted in the temporary file to the new instance of the mailbox file.
Sizes 📐
Here are the size limits, so nobody gets surprised 🎀
- The maximum length of a command line is 512 characters (including the command word and the CRLF).
- The maximum length of a reply line is 512 characters (including the success indicator (+, -, =, #) and the CRLF).
- The maximum length of a text line is 1000 characters (including CRLF).
ISI has developed a POP2 server for TOPS-20 and for Berkeley 4.2 Unix, and a POP2 client for an IBM-PC and for Berkeley 4.2 Unix. Look at them go 🧡
Extensions Not Supported 🙅♀️
POP2 doesn't look inside the internal data of messages. In particular, the server doesn't parse message headers. Hands off the contents, babe 🫶
The server doesn't keep any state information, which means it doesn't know from one session to the next what has happened. For example, the server doesn't know which messages were received since the last time the user used POP2, so it can't send just the "new" messages. Memory like a goldfish, honestly 🐠
Examples 🎀
okay bestie, these three examples are literally the best way to see POP2 in action 🦋 each one is a little chat between a Client and a Server, read top to bottom. The arrows show who says what, so you can follow the whole conversation like a group chat 💬
Example 1 💌
Client Server
------ ------
Wait for connection
Open connection -->
<-- + POP2 USC-ISIF.ARPA Server
HELO POSTEL SECRET -->
<-- #2 messages in your mailbox
READ -->
<-- =537 characters in message 1
RETR -->
<-- [data of message 1]
ACKD -->
<-- =234 characters in message 2
RETR -->
<-- [data of message 2]
ACKD -->
<-- =0 no more messages
QUIT -->
<-- + OK, bye, bye
Close connection --> <-- Close connection
Go back to startthis one is giving "connect, log in, read everything, then leave" ✨ the server says there are 2 messages, the client reads and retrieves each one, and then the server says there's nothing left 🫶
Example 2 🧚
Client Server
------ ------
Wait for connection
Open connection -->
<-- + POP2 ISI-VAXA.ARPA server here
HELO smith secret -->
<-- #35 messages
FOLD /usr/spool/mail/smith -->
<-- #27 messages
READ 27 -->
<-- =10123 characters in that message
RETR -->
<-- [data of message 27]
ACKS -->
<-- =0 no more messages
QUIT -->
<-- + bye, call again sometime.
Close connection --> <-- Close connection
Go back to startooh, this one has a FOLD step 🗂️ the client picks a mailbox first (/usr/spool/mail/smith), and then it reads message 27 specifically instead of going in order. main character energy, honestly 👑
Example 3 🥺
Client Server
------ ------
Wait for connection
Open connection -->
<-- + POP2 ISI-VAXA.ARPA server here
HELO Jones secret -->
<-- #0 messages
READ -->
<-- Close connection
Close connection -->
Go back to startand this poor little mailbox is empty 😭 the server says #0 messages, so when the client tries to READ, the connection just gets closed. not everyone gets a happy ending, bestie 💀
Formal Syntax 📐
okay so this part is the actual rulebook, but it's really just a bunch of tiny building blocks stacked on top of each other 🧱 the little names in angle brackets (like <digit> or <word>) are the pieces, and the = and | bits show how they fit together. honestly, it's so satisfying once it clicks 🫶
<digit> = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<letter> = A | B | C | ... | Z
a | b | c | ... | z
<punct> = ! | " | # | $ | % | & | ' | ( | ) | * |
+ | , | - | / | : | < | = | > | ? | @ |
[ | ] | ^ | _ | ` | { | | | } | ~
<quote> = \
<any> = any one of the 128 ASCII codes
<CR> = carriage return, code 10
<LF> = line feed, code 13
<SP> = space, code 32
<CRLF> = <CR> <LF>
<print> = <letter> | <digit> | <punct> | <quote> <any>
<char> = <print> | <SP>
<word> = <print> | <print> <word>
<string> = <char> | <char> <string>
<ld> = <letter> | <digit>
<ldh> = <letter> | <digit> | -
<ldhs> = <ldh> | <ldh> <ldhs>
<name> = <letter> [ [ <ldhs> ] <ld> ]
<host> = <name> | <name> . <host>
<user> = <word>
<password> = <word>
<mailbox> = <string>
<number> = <digit> | <digit> <number>
<helo> = HELO <SP> <user> <SP> <password> <CRLF>
<fold> = FOLD <SP> <mailbox> <CRLF>
<read> = READ [<SP> <number>] <CRLF>
<retr> = RETR <CRLF>
<acks> = ACKS <CRLF>
<ackd> = ACKD <CRLF>
<nack> = NACK <CRLF>
<quit> = QUIT <CRLF>
<ok> = + [<SP> <string>] <CRLF>
<err> = - [<SP> <string>] <CRLF>
<count> = # <number> [<SP> <string>] <CRLF>
<greet> = + <SP> POP2 <SP> <host> [<SP> <string>] <CRLF>
<length> = = <number> [<SP> <string>] <CRLF>
<command> = <helo> | <fold> | <read> | <retr> |
<acks> | <ackd> | <nack> | <quit>
<reply> = <ok> | <err> | <count> | <length> | <greet>Client State Diagram 🗺️
this is the client's little map of where it can go next 🧭 it starts in CALL, then hops between states depending on what it sends and gets back. you can totally trace a whole conversation with your finger on this one 💅
| ^ + BYE
| Open | -----
| Greet | Close
V ----- |
+-------+ QUIT +-------+
| CALL |-------------->| EXIT |
+-------+ +-------+
| ^
| Greet |
| ----- |
| HELO |
+---->+ | |
#NNN ^ | | #NNN |
---- | V V ---- |
FOLD | +-------+ QUIT |
+<---| NMBR |--------------------->+
+-------+ ^
^ | |
| | #NNN |
| | ---- |
=CCC | | READ |
---- | | |
FOLD | | =CCC |
| V ---- |
=CCC +--->+-------+ QUIT |
---- ^ | SIZE |--------------------->+
READ +<---+-------+
^ |
| | =CCC
data | | ----
---- | | RETR
ack | |
| V
+-------+
| XFER |
+-------+Server State Diagram 🖥️
and now the server's side of the story 🎀 it begins in LSTN waiting for someone to knock, then moves through AUTH, MBOX, ITEM and NEXT as the conversation goes on, until it lands in DONE 🌸
+<----------------------+ Close
| | -----
Listen | | Close
V |
+-------+ +-------+
| LSTN | | DONE |
+-------+ +-------+
| ^
| Open |
| ----- |
| Greet |
| |
| QUIT |
V ----- |
+-------+ + BYE |
| AUTH |--------------------->+
+-------+ ^
| |
| HELO |
| ---- |
| #NNN |
| |
| QUIT |
V ----- |
FOLD +--->+-------+ + BYE |
---- ^ | MBOX |--------------------->+
#NNN +<---+-------+ ^
^ | |
| | READ |
FOLD | | ---- |
---- | | =CCC |
#NNN | | QUIT |
| V ----- |
READ +--->+-------+ + BYE |
---- ^ | ITEM |--------------------->+
=CCC +<---+-------+
^ |
| | RETR
ack | | ----
---- | | data
=CCC | |
| V
+-------+
| NEXT |
+-------+Combined Flow Diagram 🌈
ok this is the whole big picture all at once 🤯 it puts the client and the server side by side, so you can see every path a conversation can take, from the first Greet all the way to the final EXIT and DONE. it looks chaotic, but it's really just the two maps stitched together 💖
+----+
|CALL|<------------------------------------------------------------+
|LSTN| ^
+----+ |
| Greet |
| |
| +----------------------------------------------------->+ |
| ^ QUIT | |
V | V |
+----+ +----+ +----+ |
|CALL| HELO |NMBR| |EXIT| |
|AUTH|------->|AUTH| |AUTH| |
+----+ +----+ +----+ |
| #NNN + Bye | |
| | |
| +------------------------------------>+ | |
| ^ QUIT | | |
V | V | |
+--->+----+ +----+ +----+ | |
FOLD ^ |NMBR| READ |SIZE| |EXIT| | |
---- | |MBOX|------->|MBOX| |MBOX| | |
#NNN +<---+----+ +----+ +----+ | |
^ | =CCC + Bye | | |
| | | | |
FOLD +<--------+ | +------------------->+ | | |
---- ^ | ^ QUIT | | | |
#NNN | V | V | | |
+--->+-----+ +----+ +----+ | | |
READ ^ |SIZE | RETR |XFER| |EXIT| | | |
---- | | ITEM|------->|ITEM| |ITEM| | | |
=CCC +<---+-----+ +----+ +----+ | | |
^ | data | | | |
| | | | | |
=CCC | V + Bye | | | |
+----+ +----+ | | | |
|SIZE| Ack |XFER| | | | |
|NEXT|<-------|NEXT| | | | |
+----+ +----+ | | | |
| | | |
| | | |
V V V |
+-------+ |
| EXIT |-->+
| DONE |
+-------+Client Decision Table 💅
okay so this is the client's cheat sheet 🧚 the rows are what the client just got (the INPUT), and the columns are what state it's currently sitting in. where they meet, you get the number of the action to take. ngl it's giving flowchart, but make it a table 🎀
| STATE |
-------+----------------------------------|
INPUT | CALL | NMBR | SIZE | XFER | EXIT |
-------+----------------------------------|
Greet | 2 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
#NNN | 1 | 3 | 1 | 1 | 6 |
-------+----------------------------------|
=CCC | 1 | 1 | 4 | 1 | 6 |
-------+----------------------------------|
data | 1 | 1 | 1 | 5 | 6 |
-------+----------------------------------|
+ Bye | 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
Close | 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
other | 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
Timeout| 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|And here are the actions the client can take, bestie 👑
- This is garbage. Send
QUIT, and go to EXIT state. 🗑️ - (a) If the greeting is right then send
HELOand go to NMBR state.- (b) Else send
QUITand go to EXIT state.
- (b) Else send
- (a) If user wants this folder and NNN > 0 then send
READand go to SIZE state.- (b) If user wants this folder and NNN = 0 then send
QUITand go to EXIT state. - (c) If user wants a different folder then send
FOLDand go to NMBR state.
- (b) If user wants this folder and NNN = 0 then send
- (a) If user wants this message and CCC > 0 then send
RETRand go to XFER state.- (b) If user wants this message and CCC = 0 then send
QUITand go to EXIT state. - (c) If user wants a different message then send
READand go to SIZE state.
- (b) If user wants this message and CCC = 0 then send
- (a) If user wants this message kept then send
ACKSand go to SIZE state.- (b) If user wants this message deleted then send
ACKDand go to SIZE state. - (c) If user wants this message again then send
NACKand go to SIZE state.
- (b) If user wants this message deleted then send
- Close the connection. 💀
Server Decision Table ✨
same energy but flipped, the server's the one reading the room 🫶 the rows are what the server gets from the client, the columns are its current state, and you look up the action number right where they cross.
| STATE
-------+-----------------------------------------
INPUT | LSTN | AUTH | MBOX | ITEM | NEXT | DONE |
-------+-----------------------------------------|
Open | 2 | 1 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
HELO | 1 | 3 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
FOLD | 1 | 1 | 5 | 5 | 1 | 1 |
-------+-----------------------------------------|
READ | 1 | 1 | 6 | 6 | 1 | 1 |
-------+-----------------------------------------|
RETR | 1 | 1 | 1 | 7 | 1 | 1 |
-------+-----------------------------------------|
ACKS | 1 | 1 | 1 | 1 | 8 | 1 |
-------+-----------------------------------------|
ACKD | 1 | 1 | 1 | 1 | 8 | 1 |
-------+-----------------------------------------|
NACK | 1 | 1 | 1 | 1 | 8 | 1 |
-------+-----------------------------------------|
QUIT | 1 | 4 | 4 | 4 | 1 | 1 |
-------+-----------------------------------------|
Close | 1 | 1 | 1 | 1 | 1 | 9 |
-------+-----------------------------------------|
other | 1 | 1 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
Timeout| | 1 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|Here are the server's actions, periodt 💖
- This is garbage. Send
- error, and Close the connection. 🙈 - Send the greeting. Go to AUTH state. 🌸
- (a) If authorized user then send
#NNNand go to MBOX state.- (b) Else send
- errorand Close the connection.
- (b) Else send
- Send
+ Byeand go to DONE state. 👋 - Send
+NNNand go to MBOX state. - Send
=CCCand go to ITEM state. - If message exists then send the data and go to NEXT state.
- Else Close the connection.
- Do what ACKS/ACKD/NACK require and go to ITEM state. 🦋
- Close the connection. 💅
Acknowledgment 🫶
we'd love to shout out everyone who gave helpful comments on the first version of POP, the one in RFC 918, and on the POP2 draft that got passed around to people who were interested 🌈
References 📚
[1] Postel, J., "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA-Internet Text Messages", RFC 822, University of Delaware, August 1982.
[3] Reynolds, J.K., "Post Office Protocol", RFC 918, USC/Information Sciences Institute, October 1984.
[4] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 923, USC/Information Sciences Institute, October 1984.
📦 where this page comes from
- ietf: rfc937 1985-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms