1 Request For Comments: draft
14 Post Office Protocol (revised)
17 Wed Jan 14 18:47:59 1987
21 Computer Science Laboratory
22 Northrop Research and Technical Center
23 Palos Verdes Peninsula
25 MRose@NRTC.NORTHROP.COM
30 This memo suggests a simple method for workstations to dynamically
31 access mail from a mailbox server. This RFC specifies a proposed
32 protocol for the ARPA Internet community, and requests discussion
33 and suggestions for improvements.
38 This memo is based on RFC918. Although similar in form to the
39 original POP proposed for the ARPA Internet community, the protocol
40 discussed in this memo is similar in spirit to the ideas
41 investigated by the MZnet project at the University of California,
44 Further, substantial work was done on examining POP in a PC-based
45 environment. This work, which resulted in additional functionality
46 in this protocol, was performed by the ACIS Networking Systems Group
47 at Stanford University. The author gratefully acknowledges their
50 Request For Comments: draft M. Rose
51 Post Office Protocol (revised) UDel
57 On certain types of smaller nodes in the ARPA Internet it is often
58 impractical to maintain a message transport system(MTS). For
59 example, a workstation may not have sufficient resources (cycles,
60 disk space) in order to permit a SMTP server and associated local
61 mail delivery system to be kept resident and continuously running.
62 Similarly, it may be expensive (or impossible) to keep a personal
63 computer interconnected to an IP-style network for long amounts of
64 time (the node is lacking the resource known as "connectivity").
66 Despite this, it is often very useful to be able to manage mail on
67 these smaller nodes, and they often support a user agent(UA) to aid
68 the tasks of mail handling. To solve this problem, a node which
69 can support an MTS entity offers a maildrop service to these less
70 endowned nodes. The Post Office Protocol (POP) is intended to
71 permit a workstation to dynamically access a maildrop on a server
72 host in a useful fashion. Usually, this means that the POP is used
73 to allow a workstation to retrieve mail that the server is holding
76 For the remainder of this memo, the term "client host" refers to a
77 host making use of the POP service, while the term "server host"
78 refers to a host which offers the POP service.
84 This memo does not specify how a client host enters mail into the
85 transport system, although a method consistent with the philosophy
86 of this memo is presented here:
88 When the user agent on a client host wishes to enter a message
89 into the transport system, it establishes an SMTP connection
90 to its relay host (this relay host could be, but need not be,
91 the POP server host for the client host).
93 If this method is followed, then the client host appears to the MTS
94 as a user agent, and should NOT be regarded as a "trusted" MTS
95 entity in any sense whatsoever. This concept, along with the role
96 of the POP as a part of a split-UA model is discussed later in this
101 Initially the server host starts the POP service by listening on
102 TCP port 109. When a client host wishes to make use of the service
103 it establishes a TCP connection with the server host. When the
104 connection is established, the POP server sends a greeting. The
105 client and POP server then exchange commands and responses
106 (respectively) until the connection is closed or aborted.
108 Commands in the POP consist of a keyword possibly followed by an
109 argument. All commands are terminated by a CRLF pair.
111 Responses in the POP consist of a success indicator and a keyword
112 possibly followed by additional information. All responses are
113 terminated by a CRLF pair. There are currently two success
114 indicators: positive ("+OK") and negative ("-ERR").
116 Responses to certain commands are multi-line. In these cases,
117 which are clearly indicated below, after sending the first line of
118 the response and a CRLF, any additional lines are sent, each
119 terminated by a CRLF pair. When all lines of the response have
120 been sent, a final line is sent, consisting of a termination octet
121 (octal code 056, ".") and a CRLF pair. If any line of the
122 multi-line response begins with the termination octet, the line is
123 "bit-stuffed" by pre-pending the termination octet to that line of
124 the response. Hence a multi-line response is terminated with the
125 five octets "CRLF.CRLF". When examining a multi-line response, the
126 client checks to see if the line begins with the termination
127 octet. If so and if octets other than CRLF follow, the the first
128 octet of the line (the termination octet) is stripped away. If so
129 and if CRLF immediately follows the termination character, then the
130 response from the POP server is ended and the line containing
131 ".CRLF" is not considered part of the multi-line response.
133 A POP session progresses through a number of states during its
134 lifetime. Once the TCP connection has been opened and the POP
135 server has sent the greeting, the session enters the AUTHORIZATION
136 state. In this state, the client must identify itself to the POP
137 server. Once the client has successfully done this, the server
138 acquires resources associated with the client's maildrop, and the
139 session enters the TRANSACTION state. In this state, the client
140 requests actions on the part of the POP server. When the client
141 has finished its transactions, the session enters the UPDATE state.
142 In this state, the POP server releases any resources acquired
143 during the TRANSACTION state and says goodbye. The TCP connection
146 The AUTHORIZATION State
148 Once the TCP connection has been opened by a POP client, the POP
149 server issues a one line greeting. This can be any string
150 terminated by CRLF. An example might be:
152 S: +OK dewey POP server ready (Comments to: PostMaster@UDel)
154 Note that this greeting is a POP reply. The POP server should always
155 give a positive response as the greeting.
157 The POP session is now in the AUTHORIZATION state. The client must
158 now issue the USER command. If the POP server responds with a
159 positive success indicator ("+OK"), then the client may issue
160 either the PASS command to complete the authorization, or the QUIT
161 command to terminate the POP session. If the POP server responds
162 with a negative success indicator ("-ERR") to the USER command,
163 then the client may either issue a new USER command or may issue
166 When the client issues the PASS command, the POP server uses the
167 argument pair from the USER and PASS commands to determine if the
168 client should be given access to the appropriate maildrop. If so,
169 the POP server then acquires an exclusive-access lock on the
170 maildrop. If the lock is successfully acquired, the POP server
171 parses the maildrop into individual messages (read note below),
172 determines the last message (if any) present in the maildrop that
173 was referenced by the RETR command, and responds with a positive
174 success indicator. The POP session now enters the TRANSACTION
175 state. If the lock can not be acquired or the client should is
176 denied access to the appropriate maildrop or the maildrop can't be
177 parsed for some reason, the POP server responds with a negative
178 success indicator. (If a lock was acquired but the POP server
179 intends to respond with a negative success indicator, the POP server
180 must release the lock prior to rejecting the command.) At this
181 point, the client may either issue a new USER command and start
182 again, or the client may issue the QUIT command.
184 NOTE: Minimal implementations of the POP need only be
185 able to break a maildrop into its component messages;
186 they need NOT be able to parse individual messages. More
187 advanced implementations may wish to have this
188 capability, for reasons discussed later.
190 After the POP server has parsed the maildrop into individual
191 messages, it assigns a message-id to each message, and notes the
192 size of the message in octets. The first message in the maildrop
193 is assigned a message-id of "1", the second is assigned "2", and so
194 on, so that the n'th message in a maildrop is assigned a message-id
195 of "n". In POP commands and responses, all message-id's and
196 message sizes are expressed in base-10.
198 It sets the "highest number accessed" to be that of the last
199 message referenced by the RETR command.
201 Here are summaries for the three POP command discussed thus far:
204 Arguments: a server specific user-id (required)
205 Restrictions: may only be given in the AUTHORIZATION state
206 after the POP greeting or after an unsuccessful USER
209 +OK name is welcome here
210 -ERR never heard of name
213 S: +OK mrose is a real hoopy frood
216 S: -ERR sorry, frated doesn't get his mail here
219 Arguments: a server/user-id specific password (required)
220 Restrictions: may only be given in the AUTHORIZATION state
221 after a successful USER command
223 +OK maildrop locked and ready
224 -ERR invalid password
225 -ERR unable to lock maildrop
228 S: +OK mrose is a real hoopy frood
230 S: +OK mrose's maildrop has 2 messages (320 octets)
233 S: +OK mrose is a real hoopy frood
235 S: -ERR unable to lock mrose's maildrop, file already locked
244 S: +OK dewey POP server signing off
248 The TRANSACTION State
250 Once the client has successfully identified itself to the POP
251 server and the POP server has locked and burst the appropriate
252 maildrop, the POP session is now in the TRANSACTION state. The
253 client may now issue any of the following POP commands repeatedly.
254 After each command, the POP server issues a response. Eventually,
255 the client issues the QUIT command and the POP session enters the
258 Here are the POP commands valid in the TRANSACTION state:
262 Restrictions: may only be given in the TRANSACTION state.
265 The POP server issues a positive response with a line
266 containing information for the maildrop. This line is
267 called a "drop listing" for that maildrop.
269 In order to simplify parsing, all POP servers are
270 required to use a certain format for drop listings. The
271 first octets present must indicate the number of messages
272 in the maildrop. Following this is the size of the
273 maildrop in octets. This memo makes no requirement on
274 what follows the maildrop size. Minimal implementations
275 should just end that line of the response with a CRLF
276 pair. More advanced implementations may include other
279 NOTE: This memo STRONGLY discourages implementations
280 from supplying additional information in the drop
281 listing. Other, optional, facilities are discussed
282 later on which permit the client to parse the
283 messages in the maildrop.
285 Note that messages marked as deleted are not counted in
295 Arguments: a message-id (optionally) If a message-id is
296 given, it may NOT refer to a message marked as deleted.
297 Restrictions: may only be given in the TRANSACTION state.
300 If an argument was given and the POP server issues a
301 positive response with a line containing information for
302 that message. This line is called a "scan listing"
305 If no argument was given and the POP server issues a
306 positive response, then the response given is multi-line.
307 After the initial +OK, for each message in the maildrop,
308 the POP server responds with a line containing information
309 for that message. This line is called a "scan listing"
312 In order to simplify parsing, all POP servers are required
313 to use a certain format for scan listings. The first
314 octets present must be the message-id of the message.
315 Following the message-id is the size of the message in
316 octets. This memo makes no requirement on what follows
317 the message size in the scan listing. Minimal
318 implementations should just end that line of the response
319 with a CRLF pair. More advanced implementations may
320 include other information, as parsed from the message.
322 NOTE: This memo STRONGLY discourages implementations
323 from supplying additional information in the scan
324 listing. Other, optional, facilities are discussed
325 later on which permit the client to parse the
326 messages in the maildrop.
328 Note that messages marked as deleted are not listed.
331 +OK scan listing follows
335 S: +OK 2 messages (320 octets)
344 S: -ERR no such message, only 2 messages in maildrop
347 Arguments: a message-id (required) This message-id may NOT
348 refer to a message marked as deleted.
349 Restrictions: may only be given in the TRANSACTION state.
352 If the POP server issues a positive response, then the
353 response given is multi-line. After the initial +OK, the
354 POP server sends the message corresponding to the given
355 message-id, being careful to bit-stuff the termination
356 character (as with all multi-line responses).
358 If the number associated with this message is higher than
359 the "highest number accessed" in the maildrop, the POP
360 server updates the "highest number accessed" to the number
361 associated with this message.
369 S: <the POP server sends the entire message here>
373 Arguments: a message-id (required) This message-id may NOT
374 refer to a message marked as deleted.
375 Restrictions: may only be given in the TRANSACTION state.
378 The POP server marks the message as deleted. Any future
379 reference to the message-id associated with the message
380 in a POP command generates an error. The POP server does
381 not actually delete the message until the POP session
382 enters the UPDATE state.
384 If the number associated with this message is higher than
385 the "highest number accessed" in the maildrop, the POP
386 server updates the "highest number accessed" to the number
387 associated with this message.
394 S: +OK message 1 deleted
397 S: -ERR message 2 already deleted
401 Restrictions: may only be given in the TRANSACTION state.
404 The POP server does nothing, it merely replies with a
415 Restrictions: may only be issued in the TRANSACTION state.
418 The POP server issues a positive response with a line
419 containing the highest message number which accessed.
420 Zero is returned in case no message in the maildrop has
421 been accessed during previous transactions. A client
422 may thereafter infer that messages, if any, numbered greater
423 than the response to the LAST command are messages not yet
424 accessed by the client.
436 S: <the POP server sends the entire message here>
441 S: +OK message 2 deleted
451 Restrictions: may only be given in the TRANSACTION state.
454 If any messages have been marked as deleted by the POP
455 server, they are unmarked. The POP server then replies
456 with a positive response. In addition, the "highest
457 number accessed" is also reset to the value determined
458 at the beginning of the POP session.
464 S: +OK maildrop has 2 messages (320 octets)
470 When the client issues the QUIT command from the TRANSACTION state
471 the POP session enters the UPDATE state. (Note that if the client
472 issues the QUIT command from the AUTHORIZATION state, the POP
473 session terminates but does NOT enter the UPDATE state).
480 The POP server removes all messages marked as deleted
481 from the maildrop. It then releases the exclusive-access
482 lock on the maildrop and replies as to the success of
483 these operations. The TCP connection is then closed.
489 S: +OK dewey POP server signing off (maildrop empty)
492 S: +OK dewey POP server signing off (2 messages left)
495 Optional POP Commands
497 The POP commands discussed above must be supported by all minimal
498 implementations of POP servers.
500 The optional POP commands described below permit a POP client
501 greater freedom in message handling, while preserving a simple POP
502 server implementation.
504 NOTE: This memo STRONGLY encourages implementations to
505 support these commands in lieu of developing augmented
506 drop and scan listings. In short, the philosophy of this
507 memo is to put intelligence in the part of the POP client
508 and not the POP server.
511 Arguments: a message-id (required) and a number. This
512 message-id may NOT refer to a message marked as deleted.
513 Restrictions: may only be given in the TRANSACTION state.
516 If the POP server issues a positive response, then the
517 response given is multi-line. After the initial +OK, the
518 POP server sends the headers of the message, the blank
519 line separating the headers from the body, and then the
520 number of lines indicated message's body, being careful to
521 bit-stuff the termination character (as with all
522 multi-line responses).
524 Note that if the number of lines requested by the POP
525 client is greater than than the number of lines in the
526 body, then the POP server sends the entire message.
529 +OK top of message follows
534 S: <the POP server sends the headers of the message,
535 a blank line, and the first 10 lines of the
540 S: -ERR no such message
543 Arguments: a client specific user-id (required)
544 Restrictions: may only be given in the AUTHORIZATION state
545 after a successful USER command; in addition, may
546 only be given if the client used a reserved (privileged)
547 TCP port to connect to the server.
550 The RPOP command may be used instead of the PASS command
551 to authenticate access to the maildrop. In order for this
552 command to be successful, the POP client must use a
553 reserved TCP port (port < 1024) to connect to the server.
554 The POP server uses the argument pair from the USER and
555 RPOP commands to determine if the client should be given
556 access to the appropriate maildrop. Unlike the PASS
557 command however, the POP server considers if the remote
558 user specified by the RPOP command who resides on the POP
559 client host is allowed to access the maildrop for the user
560 specified by the USER command (e.g., on Berkeley UNIX, the
561 .rhosts mechanism is used). With the exception of this
562 differing in authentication, this command is identical to
566 +OK maildrop locked and ready
567 -ERR permission denied
570 S: +OK mrose is a real hoopy frood
572 S: +OK mrose's maildrop has 2 messages (320 octets)
574 POP Command/Reply Summary
576 Minimal POP Commands:
577 USER name valid in the AUTHORIZATION state
581 STAT valid in the TRANSACTION state
589 QUIT valid in the UPDATE state
591 Optional POP Commands:
592 RPOP user valid in the AUTHORIZATION state
594 TOP msg n valid in the TRANSACTION state
600 Note that with the exception of the STAT command, the reply given
601 by the POP server to any command is significant only to "+OK" and
602 "-ERR". Any text occurring after this reply may be ignored by the
607 S: <wait for connection on TCP port 109>
610 S: +OK dewey POP server ready (Comments to: PostMaster@UDel)
612 S: +OK mrose is a real hoopy frood
614 S: +OK mrose's maildrop has 2 messages (320 octets)
618 S: +OK 2 messages (320 octets)
624 S: <the POP server sends message 1>
627 S: +OK message 1 deleted
630 S: <the POP server sends message 2>
633 S: +OK message 2 deleted
635 S: +OK dewey POP server signing off (maildrop empty)
636 C: <close connection>
637 S: <wait for next connection>
643 All messages transmitted during a POP session are assumed to
644 conform to the standard for the format of ARPA Internet text
647 It is important to note that the byte count for a message on the
648 server host may differ from the octet count assigned to that
649 message due to local conventions for designating end-of-line.
650 Usually, during the AUTHORIZATION state of the POP session, the POP
651 client can calculate the size of each message in octets when it
652 parses the maildrop into messages. For example, if the POP server
653 host internally represents end-of-line as a single character, then
654 the POP server simply counts each occurrence of this character in a
655 message as two octets. Note that lines in the message which start
656 with the termination octet need not be counted twice, since the POP
657 client will remove all bit-stuffed termination characters when it
658 receives a multi-line response.
662 The POP and the Split-UA model
664 The underlying paradigm in which the POP functions is that of a
665 split-UA model. The POP client host, being a remote PC based
666 workstation, acts solely as a client to the message transport
667 system. It does not provide delivery/authentication services to
668 others. Hence, it is acting as a UA, on behalf of the person using
669 the workstation. Furthermore, the workstation uses SMTP to enter
672 In this sense we have two UA functions which interface to the
673 message transport system: Posting (SMTP) and Retrieval (POP). The
674 entity which supports this type of environment is called a split-UA
675 (since the user agent is split between two hosts which must
676 interoperate to provide these functions).
678 ASIDE: Others might term this a remote-UA instead. There
679 are arguments supporting the use of both terms.
681 This memo has explicitly referenced TCP as the underlying transport
682 agent for the POP. This need not be the case. In the MZnet
683 split-UA, for example, personal micro-computer systems are used
684 which do not have IP-style networking capability. To connect to
685 the POP server host, a PC establishes a terminal connection using
686 some simple protocol (PhoneNet). A program on the PC drives the
687 connection, first establishing a login session as a normal user.
688 The login shell for this pseudo-user is a program which drives the
689 other half of the terminal protocol and communicates with one of
690 two servers. Although MZnet can support several PCs, a single
691 pseudo-user login is present on the server host. The user-id and
692 password for this pseudo-user login is known to all members of
693 MZnet. Hence, the first action of the login shell, after starting
694 the terminal protocol, is to demand a USER/PASS authorization pair
695 from the PC. This second level of authorization is used to
696 ascertain who is interacting with the MTS. Although the server host
697 is deemed to support a "trusted" MTS entity, PCs in MZnet are not.
698 Naturally, the USER/PASS authorization pair for a PC is known only
699 to the owner of the PC (in theory, at least).
701 After successfully verifying the identity of the client, a modified
702 SMTP server is started, and the PC posts mail with the server host.
703 After the QUIT command is given to the SMTP server and it
704 terminates, a modified POP server is started, and the PC retrieves
705 mail from the server host. After the QUIT command is given to the
706 POP server and it terminates, the login shell for the pseudo-user
707 terminates the terminal protocol and logs the job out. The PC then
708 closes the terminal connection to the server host.
710 The SMTP server used by MZnet is modified in the sense that it
711 knows that it's talking to a user agent and not a "trusted" entity
712 in the message transport system. Hence, it does performs the
713 validation activities normally performed by an entity in the MTS
714 when it accepts a message from a UA.
716 The POP server used by MZnet is modified in the sense that it does
717 not require a USER/PASS combination before entering the TRANSACTION
718 state. The reason for this (of course) is that the PC has already
719 identified itself during the second-level authorization step
722 NOTE: Truth in advertising laws require that the author
723 of this memo state that MZnet has not actually been fully
724 implemented. The concepts presented and proven by the
725 project led to the notion of the MZnet split-slot model.
726 This notion has inspired the split-UA concept described
727 in this memo, led to the author's interest in the POP,
728 and heavily influenced the the description of the POP
731 In fact, some UAs present in the ARPA Internet already support the
732 notion of posting directly to an SMTP server and retreiving mail
733 directly from a POP server, even if the POP server and client
734 resided on the same host!
736 ASIDE: this discussion raises an issue which this memo
737 purposedly avoids: how does SMTP know that it's talking
738 to a "trusted" MTS entity?
742 [MZnet] E.A. Stefferud, J.N. Sweet, T.P. Domae.
743 "MZnet: Mail Service for Personal Micro-Computer
744 Systems", Proceedings, IFIP 6.5 International
745 Conference on Computer Message Systems, Nottingham, U.K.
748 [RFC821] J.B. Postel.
749 "Simple Mail Transfer Protocol", USC/Information Sciences
750 Institute. (August, 1982)
752 [RFC822] D.H. Crocker.
753 "Standard for the Format of ARPA Internet Text
754 Messages", University of Delaware. (August, 1982)
756 [RFC918] J.K. Reynolds.
757 "Post Office Protocol", USC/Information Sciences Institute.
760 [RFC923] J.K. Reynolds, J.B. Postel.
761 "Assigned Numbers", USC/Information Sciences Institute.