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