![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to pop.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / mh / support / pop|
Return to pop.txt CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / mh / support / pop |
1.1 root 1: Request For Comments: draft
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14: Post Office Protocol (revised)
15:
16:
17: Sun Oct 28 19:40:26 1984
18:
19: Last Revision
20: Wed Oct 23 20:54:26 1985
21:
22: Marshall T. Rose
23:
24: Department of Computer and Information Sciences
25: University of Delaware
26: Newark, DE 19716
27:
28: MRose@UDel
29:
30:
31:
32:
33: This memo suggests a simple method for workstations to dynamically
34: access mail from a mailbox server. This RFC specifies a proposed
35: protocol for the ARPA Internet community, and requests discussion
36: and suggestions for improvements.
37:
38:
39: Acknowledgements
40:
41: This memo is based on RFC918. Although similar in form to the
42: original POP proposed for the ARPA Internet community, the protocol
43: discussed in this memo is similar in spirit to the ideas
44: investigated by the MZnet project at the University of California,
45: Irvine.
46:
47: Request For Comments: draft M. Rose
48: Post Office Protocol (revised) UDel
49:
50:
51:
52: Introduction
53:
54: On certain types of smaller nodes in the ARPA Internet it is often
55: impractical to maintain a message transport system(MTS). For
56: example, a workstation may not have sufficient resources (cycles,
57: disk space) in order to permit a SMTP server and associated local
58: mail delivery system to be kept resident and continuously running.
59: Similarly, it may be expensive (or impossible) to keep a personal
60: computer interconnected to an IP-style network for long amounts of
61: time (the node is lacking the resource known as "connectivity").
62:
63: Despite this, it is often very useful to be able to manage mail on
64: these smaller nodes, and they often support a user agent(UA) to aid
65: the tasks of mail handling. To solve this problem, a node which
66: can support an MTS entity offers a maildrop service to these less
67: endowned nodes. The Post Office Protocol (POP) is intended to
68: permit a workstation to dynamically access a maildrop on a server
69: host in a useful fashion. Usually, this means that the POP is used
70: to allow a workstation to retrieve mail that the server is holding
71: for it.
72:
73: For the remainder of this memo, the term "client host" refers to a
74: host making use of the POP service, while the term "server host"
75: refers to a host which offers the POP service.
76:
77: The status of this protocol is experimental.
78:
79:
80:
81: A Short Digression
82:
83: This memo does not specify how a client host enters mail into the
84: transport system, although a method consistent with the philosophy
85: of this memo is presented here:
86:
87: When the user agent on a client host wishes to enter a message
88: into the transport system, it establishes an SMTP connection
89: to its relay host (this relay host could be, but need not be,
90: the POP server host for the client host).
91:
92: If this method is followed, then the client host appears to the MTS
93: as a user agent, and should NOT be regarded as a "trusted" MTS
94: entity in any sense whatsoever. This concept, along with the role
95: of the POP as a part of a split-UA model is discussed later in this
96: memo.
97:
98: The Protocol
99:
100: Initially the server host starts the POP service by listening on
101: TCP port 109. When a client host wishes to make use of the service
102: it establishes a TCP connection with the server host. When the
103: connection is established, the POP server sends a greeting. The
104: client and POP server then exchange commands and responses
105: (respectively) until the connection is closed or aborted.
106:
107: Commands in the POP consist of a keyword possibly followed by an
108: argument. All commands are terminated by a CRLF pair.
109:
110: Responses in the POP consist of a success indicator and a keyword
111: possibly followed by additional information. All responses are
112: terminated by a CRLF pair. There are currently two success
113: indicators: positive ("+OK") and negative ("-ERR").
114:
115: Responses to certain commands are multi-line. In these cases,
116: which are clearly indicated below, after sending the first line of
117: the response and a CRLF, any additional lines are sent, each
118: terminated by a CRLF pair. When all lines of the response have
119: been sent, a final line is sent, consisting of a termination octet
120: (octal code 056, ".") and a CRLF pair. If any line of the
121: multi-line response begins with the termination octet, the line is
122: "bit-stuffed" by pre-pending the termination octet to that line of
123: the response. Hence a multi-line response is terminated with the
124: five octets "CRLF.CRLF". When examining a multi-line response, the
125: client checks to see if the line begins with the termination
126: octet. If so and if octets other than CRLF follow, the the first
127: octet of the line (the termination octet) is stripped away. If so
128: and if CRLF immediately follows the termination character, then the
129: response from the POP server is ended and the line containing
130: ".CRLF" is not considered part of the multi-line response.
131:
132: A POP session progresses through a number of states during its
133: lifetime. Once the TCP connection has been opened and the POP
134: server has sent the greeting, the session enters the AUTHORIZATION
135: state. In this state, the client must identify itself to the POP
136: server. Once the client has successfully done this, the server
137: acquires resources associated with the client's maildrop, and the
138: session enters the TRANSACTION state. In this state, the client
139: requests actions on the part of the POP server. When the client
140: has finished its transactions, the session enters the UPDATE state.
141: In this state, the POP server releases any resources acquired
142: during the TRANSACTION state and says goodbye. The TCP connection
143: is then closed.
144:
145: The AUTHORIZATION State
146:
147: Once the TCP connection has been opened by a POP client, the POP
148: server issues a one line greeting. This can be any string
149: terminated by CRLF. An example might be:
150:
151: S: +OK dewey POP server ready (Comments to: PostMaster@UDel)
152:
153: Note that this greeting is a POP reply. The POP server should always
154: give a positive response as the greeting.
155:
156: The POP session is now in the AUTHORIZATION state. The client must
157: now issue the USER command. If the POP server responds with a
158: positive success indicator ("+OK"), then the client may issue
159: either the PASS command to complete the authorization, or the QUIT
160: command to terminate the POP session. If the POP server responds
161: with a negative success indicator ("-ERR") to the USER command,
162: then the client may either issue a new USER command or may issue
163: the QUIT command.
164:
165: When the client issues the PASS command, the POP server uses the
166: argument pair from the USER and PASS commands to determine if the
167: client should be given access to the appropriate maildrop. If so,
168: the POP server then acquires an exclusive-access lock on the
169: maildrop. If the lock is successfully acquired, the POP server
170: parses the maildrop into individual messages (read note below) and
171: responds with a positive success indicator. The POP session now
172: enters the TRANSACTION state. If the lock can not be acquired or
173: the client should is denied access to the appropriate maildrop or
174: the maildrop can't be parsed for some reason, the POP server
175: responds with a negative success indicator. (If a lock was
176: acquired but the POP server intends to respond with a negative
177: success indicator, the POP server must release the lock prior to
178: rejecting the command.) At this point, the client may either issue
179: a new USER command and start again, or the client may issue the
180: QUIT command.
181:
182: NOTE: Minimal implementations of the POP need only be
183: able to break a maildrop into its component messages;
184: they need NOT be able to parse individual messages. More
185: advanced implementations may wish to have this
186: capability, for reasons discussed later.
187:
188: After the POP server has parsed the maildrop into individual
189: messages, it assigns a message-id to each message, and notes the
190: size of the message in octets. The first message in the maildrop
191: is assigned a message-id of "1", the second is assigned "2", and so
192: on, so that the n'th message in a maildrop is assigned a message-id
193: of "n". In POP commands and responses, all message-id's and
194: message sizes are expressed in base-10.
195:
196: Here are summaries for the three POP command discussed thus far:
197:
198: USER name
199: Arguments: a server specific user-id (required)
200: Restrictions: may only be given in the AUTHORIZATION state
201: after the POP greeting or after an unsuccessful USER
202: or PASS command
203: Possible Responses:
204: +OK name is welcome here
205: -ERR never heard of name
206: Examples:
207: C: USER mrose
208: S: +OK mrose is a real hoopy frood
209: ...
210: C: USER frated
211: S: -ERR sorry, frated doesn't get his mail here
212:
213: PASS string
214: Arguments: a server/user-id specific password (required)
215: Restrictions: may only be given in the AUTHORIZATION state
216: after a successful USER command
217: Possible Responses:
218: +OK maildrop locked and ready
219: -ERR invalid password
220: -ERR unable to lock maildrop
221: Examples:
222: C: USER mrose
223: S: +OK mrose is a real hoopy frood
224: C: PASS secret
225: S: +OK mrose's maildrop has 2 messages (320 octets)
226: ...
227: C: USER mrose
228: S: +OK mrose is a real hoopy frood
229: C: PASS secret
230: S: -ERR unable to lock mrose's maildrop, file already locked
231:
232: QUIT
233: Arguments: none
234: Restrictions: none
235: Possible Responses:
236: +OK
237: Examples:
238: C: QUIT
239: S: +OK dewey POP server signing off
240:
241:
242:
243: The TRANSACTION State
244:
245: Once the client has successfully identified itself to the POP
246: server and the POP server has locked and burst the appropriate
247: maildrop, the POP session is now in the TRANSACTION state. The
248: client may now issue any of the following POP commands repeatedly.
249: After each command, the POP server issues a response. Eventually,
250: the client issues the QUIT command and the POP session enters the
251: UPDATE state.
252:
253: Here are the POP commands valid in the TRANSACTION state:
254:
255: STAT
256: Arguments: none
257: Restrictions: may only be given in the TRANSACTION state.
258: Discussion:
259:
260: The POP server issues a positive response with a line
261: containing information for the maildrop. This line is
262: called a "drop listing" for that maildrop.
263:
264: In order to simplify parsing, all POP servers are
265: required to use a certain format for drop listings. The
266: first octets present must indicate the number of messages
267: in the maildrop. Following this is the size of the
268: maildrop in octets. This memo makes no requirement on
269: what follows the maildrop size. Minimal implementations
270: should just end that line of the response with a CRLF
271: pair. More advanced implementations may include other
272: information.
273:
274: NOTE: This memo STRONGLY discourages implementations
275: from supplying additional information in the drop
276: listing. Other, optional, facilities are discussed
277: later on which permit the client to parse the
278: messages in the maildrop.
279:
280: Note that messages marked as deleted are not counted in
281: either total.
282:
283: Possible Responses:
284: +OK nn mm
285: Examples:
286: C: STAT
287: S: +OK 2 320
288:
289: LIST [msg]
290: Arguments: a message-id (optionally) If a message-id is
291: given, it may NOT refer to a message marked as deleted.
292: Restrictions: may only be given in the TRANSACTION state.
293: Discussion:
294:
295: If an argument was given and the POP server issues a
296: positive response with a line containing information for
297: that message. This line is called a "scan listing"
298: for that message.
299:
300: If no argument was given and the POP server issues a
301: positive response, then the response given is multi-line.
302: After the initial +OK, for each message in the maildrop,
303: the POP server responds with a line containing information
304: for that message. This line is called a "scan listing"
305: for that message.
306:
307: In order to simplify parsing, all POP servers are required
308: to use a certain format for scan listings. The first
309: octets present must be the message-id of the message.
310: Following the message-id is the size of the message in
311: octets. This memo makes no requirement on what follows
312: the message size in the scan listing. Minimal
313: implementations should just end that line of the response
314: with a CRLF pair. More advanced implementations may
315: include other information, as parsed from the message.
316:
317: NOTE: This memo STRONGLY discourages implementations
318: from supplying additional information in the scan
319: listing. Other, optional, facilities are discussed
320: later on which permit the client to parse the
321: messages in the maildrop.
322:
323: Note that messages marked as deleted are not listed.
324:
325: Possible Responses:
326: +OK scan listing follows
327: -ERR no such message
328: Examples:
329: C: LIST
330: S: +OK 2 messages (320 octets)
331: S: 1 120
332: S: 2 200
333: S: .
334: ...
335: C: LIST 2
336: S: +OK 2 200
337: ...
338: C: LIST 3
339: S: -ERR no such message, only 2 messages in maildrop
340:
341: RETR msg
342: Arguments: a message-id (required) This message-id may NOT
343: refer to a message marked as deleted.
344: Restrictions: may only be given in the TRANSACTION state.
345: Discussion:
346:
347: If the POP server issues a positive response, then the
348: response given is multi-line. After the initial +OK, the
349: POP server sends the message corresponding to the given
350: message-id, being careful to bit-stuff the termination
351: character (as with all multi-line responses).
352:
353: Possible Responses:
354: +OK message follows
355: -ERR no such message
356: Examples:
357: C: RETR 1
358: S: +OK 120 octets
359: S: <the POP server sends the entire message here>
360: S: .
361:
362: DELE msg
363: Arguments: a message-id (required) This message-id may NOT
364: refer to a message marked as deleted.
365: Restrictions: may only be given in the TRANSACTION state.
366: Discussion:
367:
368: The POP server marks the message as deleted. Any future
369: reference to the message-id associated with the message
370: in a POP command generates an error. The POP server does
371: not actually delete the message until the POP session
372: enters the UPDATE state.
373:
374: Possible Responses:
375: +OK message deleted
376: -ERR no such message
377: Examples:
378: C: DELE 1
379: S: +OK message 1 deleted
380: ...
381: C: DELE 2
382: S: -ERR message 2 already deleted
383:
384: NOOP
385: Arguments: none
386: Restrictions: may only be given in the TRANSACTION state.
387: Discussion:
388:
389: The POP server does nothing, it merely replies with a
390: positive response.
391:
392: Possible Responses:
393: +OK
394: Examples:
395: C: NOOP
396: S: +OK
397:
398: RSET
399: Arguments: none
400: Restrictions: may only be given in the TRANSACTION state.
401: Discussion:
402:
403: If any messages have been marked as deleted by the POP
404: server, they are unmarked. The POP server then replies
405: with a positive response.
406:
407: Possible Responses:
408: +OK
409: Examples:
410: C: RSET
411: S: +OK maildrop has 2 messages (320 octets)
412:
413:
414:
415: The UPDATE State
416:
417: When the client issues the QUIT command from the TRANSACTION state
418: the POP session enters the UPDATE state. (Note that if the client
419: issues the QUIT command from the AUTHORIZATION state, the POP
420: session terminates but does NOT enter the UPDATE state).
421:
422: QUIT
423: Arguments: none
424: Restrictions: none
425: Discussion:
426:
427: The POP server removes all messages marked as deleted
428: from the maildrop. It then releases the exclusive-access
429: lock on the maildrop and replies as to the success of
430: these operations. The TCP connection is then closed.
431:
432: Possible Responses:
433: +OK
434: Examples:
435: C: QUIT
436: S: +OK dewey POP server signing off (maildrop empty)
437: ...
438: C: QUIT
439: S: +OK dewey POP server signing off (2 messages left)
440: ...
441:
442: Optional POP Commands
443:
444: The POP commands discussed above must be supported by all minimal
445: implementations of POP servers.
446:
447: The optional POP commands described below permit a POP client
448: greater freedom in message handling, while preserving a simple POP
449: server implementation.
450:
451: NOTE: This memo STRONGLY encourages implementations to
452: support these commands in lieu of developing augmented
453: drop and scan listings. In short, the philosophy of this
454: memo is to put intelligence in the part of the POP client
455: and not the POP server.
456:
457: TOP msg n
458: Arguments: a message-id (required) and a number. This
459: message-id may NOT refer to a message marked as deleted.
460: Restrictions: may only be given in the TRANSACTION state.
461: Discussion:
462:
463: If the POP server issues a positive response, then the
464: response given is multi-line. After the initial +OK, the
465: POP server sends the headers of the message, the blank
466: line separating the headers from the body, and then the
467: number of lines indicated message's body, being careful to
468: bit-stuff the termination character (as with all
469: multi-line responses).
470:
471: Note that if the number of lines requested by the POP
472: client is greater than than the number of lines in the
473: body, then the POP server sends the entire message.
474:
475: Possible Responses:
476: +OK top of message follows
477: -ERR no such message
478: Examples:
479: C: TOP 10
480: S: +OK
481: S: <the POP server sends the headers of the message,
482: a blank line, and the first 10 lines of the
483: body of the message>
484: S: .
485: ...
486: C: TOP 100
487: S: -ERR no such message
488:
489: RPOP user
490: Arguments: a client specific user-id (required)
491: Restrictions: may only be given in the AUTHORIZATION state
492: after a successful USER command; in addition, may
493: only be given if the client used a reserved (privileged)
494: TCP port to connect to the server.
495: Discussion:
496:
497: The RPOP command may be used instead of the PASS command
498: to authenticate access to the maildrop. In order for this
499: command to be successful, the POP client must use a
500: reserved TCP port (port < 1024) to connect to the server.
501: The POP server uses the argument pair from the USER and
502: RPOP commands to determine if the client should be given
503: access to the appropriate maildrop. Unlike the PASS
504: command however, the POP server considers if the remote
505: user specified by the RPOP command who resides on the POP
506: client host is allowed to access the maildrop for the user
507: specified by the USER command (e.g., on Berkeley UNIX, the
508: .rhosts mechanism is used). With the exception of this
509: differing in authentication, this command is identical to
510: the PASS command.
511:
512: Possible Responses:
513: +OK maildrop locked and ready
514: -ERR permission denied
515: Examples:
516: C: USER mrose
517: S: +OK mrose is a real hoopy frood
518: C: RPOP mrose
519: S: +OK mrose's maildrop has 2 messages (320 octets)
520:
521: POP Command/Reply Summary
522:
523: Minimal POP Commands:
524: USER name valid in the AUTHORIZATION state
525: PASS string
526: QUIT
527:
528: STAT valid in the TRANSACTION state
529: LIST [msg]
530: RETR msg
531: DELE msg
532: NOOP
533: RSET
534:
535: QUIT valid in the UPDATE state
536:
537: Optional POP Commands:
538: RPOP user valid in the AUTHORIZATION state
539:
540: TOP msg n valid in the TRANSACTION state
541:
542: POP Replies:
543: +OK
544: -ERR
545:
546: Note that with the exception of the STAT command, the reply given
547: by the POP server to any command is significant only to "+OK" and
548: "-ERR". Any text occurring after this reply may be ignored by the
549: client.
550:
551: Example POP Session
552:
553: S: <wait for connection on TCP port 109>
554: ...
555: C: <open connection>
556: S: +OK dewey POP server ready (Comments to: PostMaster@UDel)
557: C: USER mrose
558: S: +OK mrose is a real hoopy frood
559: C: PASS secret
560: S: +OK mrose's maildrop has 2 messages (320 octets)
561: C: STAT
562: S: +OK 2 320
563: C: LIST
564: S: +OK 2 messages (320 octets)
565: S: 1 120
566: S: 2 200
567: S: .
568: C: RETR 1
569: S: +OK 120 octets
570: S: <the POP server sends message 1>
571: S: .
572: C: DELE 1
573: S: +OK message 1 deleted
574: C: RETR 2
575: S: +OK 200 octets
576: S: <the POP server sends message 2>
577: S: .
578: C: DELE 2
579: S: +OK message 2 deleted
580: C: QUIT
581: S: +OK dewey POP server signing off (maildrop empty)
582: C: <close connection>
583: S: <wait for next connection>
584:
585:
586:
587: Message Format
588:
589: All messages transmitted during a POP session are assumed to
590: conform to the standard for the format of ARPA Internet text
591: messages [RFC822].
592:
593: It is important to note that the byte count for a message on the
594: server host may differ from the octet count assigned to that
595: message due to local conventions for designating end-of-line.
596: Usually, during the AUTHORIZATION state of the POP session, the POP
597: client can calculate the size of each message in octets when it
598: parses the maildrop into messages. For example, if the POP server
599: host internally represents end-of-line as a single character, then
600: the POP server simply counts each occurrence of this character in a
601: message as two octets. Note that lines in the message which start
602: with the termination octet need not be counted twice, since the POP
603: client will remove all bit-stuffed termination characters when it
604: receives a multi-line response.
605:
606:
607:
608: The POP and the Split-UA model
609:
610: The underlying paradigm in which the POP functions is that of a
611: split-UA model. The POP client host, being a remote PC based
612: workstation, acts solely as a client to the message transport
613: system. It does not provide delivery/authentication services to
614: others. Hence, it is acting as a UA, on behalf of the person using
615: the workstation. Furthermore, the workstation uses SMTP to enter
616: mail into the MTS.
617:
618: In this sense we have two UA functions which interface to the
619: message transport system: Posting (SMTP) and Retrieval (POP). The
620: entity which supports this type of environment is called a split-UA
621: (since the user agent is split between two hosts which must
622: interoperate to provide these functions).
623:
624: ASIDE: Others might term this a remote-UA instead. There
625: are arguments supporting the use of both terms.
626:
627: This memo has explicitly referenced TCP as the underlying transport
628: agent for the POP. This need not be the case. In the MZnet
629: split-UA, for example, personal micro-computer systems are used
630: which do not have IP-style networking capability. To connect to
631: the POP server host, a PC establishes a terminal connection using
632: some simple protocol (PhoneNet). A program on the PC drives the
633: connection, first establishing a login session as a normal user.
634: The login shell for this pseudo-user is a program which drives the
635: other half of the terminal protocol and communicates with one of
636: two servers. Although MZnet can support several PCs, a single
637: pseudo-user login is present on the server host. The user-id and
638: password for this pseudo-user login is known to all members of
639: MZnet. Hence, the first action of the login shell, after starting
640: the terminal protocol, is to demand a USER/PASS authorization pair
641: from the PC. This second level of authorization is used to
642: ascertain who is interacting with the MTS. Although the server host
643: is deemed to support a "trusted" MTS entity, PCs in MZnet are not.
644: Naturally, the USER/PASS authorization pair for a PC is known only
645: to the owner of the PC (in theory, at least).
646:
647: After successfully verifying the identity of the client, a modified
648: SMTP server is started, and the PC posts mail with the server host.
649: After the QUIT command is given to the SMTP server and it
650: terminates, a modified POP server is started, and the PC retrieves
651: mail from the server host. After the QUIT command is given to the
652: POP server and it terminates, the login shell for the pseudo-user
653: terminates the terminal protocol and logs the job out. The PC then
654: closes the terminal connection to the server host.
655:
656: The SMTP server used by MZnet is modified in the sense that it
657: knows that it's talking to a user agent and not a "trusted" entity
658: in the message transport system. Hence, it does performs the
659: validation activities normally performed by an entity in the MTS
660: when it accepts a message from a UA.
661:
662: The POP server used by MZnet is modified in the sense that it does
663: not require a USER/PASS combination before entering the TRANSACTION
664: state. The reason for this (of course) is that the PC has already
665: identified itself during the second-level authorization step
666: described above.
667:
668: NOTE: Truth in advertising laws require that the author
669: of this memo state that MZnet has not actually been fully
670: implemented. The concepts presented and proven by the
671: project led to the notion of the MZnet split-slot model.
672: This notion has inspired the split-UA concept described
673: in this memo, led to the author's interest in the POP,
674: and heavily influenced the the description of the POP
675: herein.
676:
677: In fact, some UAs present in the ARPA Internet already support the
678: notion of posting directly to an SMTP server and retreiving mail
679: directly from a POP server, even if the POP server and client
680: resided on the same host!
681:
682: ASIDE: this discussion raises an issue which this memo
683: purposedly avoids: how does SMTP know that it's talking
684: to a "trusted" MTS entity?
685:
686: References
687:
688: [MZnet] E.A. Stefferud, J.N. Sweet, T.P. Domae.
689: "MZnet: Mail Service for Personal Micro-Computer
690: Systems", Proceedings, IFIP 6.5 International
691: Conference on Computer Message Systems, Nottingham, U.K.
692: (May, 1984)
693:
694: [RFC821] J.B. Postel.
695: "Simple Mail Transfer Protocol", USC/Information Sciences
696: Institute. (August, 1982)
697:
698: [RFC822] D.H. Crocker.
699: "Standard for the Format of ARPA Internet Text
700: Messages", University of Delaware. (August, 1982)
701:
702: [RFC918] J.K. Reynolds.
703: "Post Office Protocol", USC/Information Sciences Institute.
704: (October, 1984)
705:
706: [RFC923] J.K. Reynolds, J.B. Postel.
707: "Assigned Numbers", USC/Information Sciences Institute.
708: (October, 1984)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.