Return to pop.rfc CVS log

Up to [CSRG BSD Unix] / 43BSD / contrib / mh / support / pop

Annotation of 43BSD/contrib/mh/support/pop/pop.rfc, revision 1.1

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.