crypto/heimdal-0.6.3/appl/popper/pop3.rfc1081

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