zilinlin/RFC2PSM huggingface dataset:
Section 1. Introduction

On certain types of smaller nodes in the Internet it is often
   impractical to maintain a message transport system (MTS).  For
   example, a workstation may not have sufficient resources (cycles,
   disk space) in order to permit a SMTP server [RFC821] and associated
   local mail delivery system to be kept resident and continuously
   running.  Similarly, it may be expensive (or impossible) to keep a
   personal computer interconnected to an IP-style network for long
   amounts of time (the node is lacking the resource known as
   "connectivity").
   Despite this, it is often very useful to be able to manage mail on
   these smaller nodes, and they often support a user agent (UA) to aid
   the tasks of mail handling.  To solve this problem, a node which can
   support an MTS entity offers a maildrop service to these less endowed
   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
   permit a workstation to dynamically access a maildrop on a server
   host in a useful fashion.  Usually, this means that the POP3 protocol
   is used to allow a workstation to retrieve mail that the server is
   holding for it.
   POP3 is not intended to provide extensive manipulation operations of
   mail on the server; normally, mail is downloaded and then deleted.  A
   more advanced (and complex) protocol, IMAP4, is discussed in
   [RFC1730].
   For the remainder of this memo, the term "client host" refers to a
   host making use of the POP3 service, while the term "server host"
   refers to a host which offers the POP3 service.
Section 2. A Short Digression

This memo does not specify how a client host enters mail into the
   transport system, although a method consistent with the philosophy of
   this memo is presented here:
      When the user agent on a client host wishes to enter a message
      into the transport system, it establishes an SMTP connection to
      its relay host and sends all mail to it.  This relay host could
      be, but need not be, the POP3 server host for the client host.  Of
      course, the relay host must accept mail for delivery to arbitrary
      recipient addresses, that functionality is not required of all
      SMTP servers.
Section 4. The AUTHORIZATION State

Once the TCP connection has been opened by a POP3 client, the POP3
   server issues a one line greeting.  This can be any positive
   response.  An example might be:
      S:  +OK POP3 server ready
   The POP3 session is now in the AUTHORIZATION state.  The client must
   now identify and authenticate itself to the POP3 server.  Two
   possible mechanisms for doing this are described in this document,
   the USER and PASS command combination and the APOP command.  Both
   mechanisms are described later in this document.  Additional
   authentication mechanisms are described in [RFC1734].  While there is
   no single authentication mechanism that is required of all POP3
   servers, a POP3 server must of course support at least one
   authentication mechanism.
   Once the POP3 server has determined through the use of any
   authentication command that the client should be given access to the
   appropriate maildrop, the POP3 server then acquires an exclusive-
   access lock on the maildrop, as necessary to prevent messages from
   being modified or removed before the session enters the UPDATE state.
   If the lock is successfully acquired, the POP3 server responds with a
   positive status indicator.  The POP3 session now enters the
   TRANSACTION state, with no messages marked as deleted.  If the
   maildrop cannot be opened for some reason (for example, a lock can
   not be acquired, the client is denied access to the appropriate
   maildrop, or the maildrop cannot be parsed), the POP3 server responds
   with a negative status indicator.  (If a lock was acquired but the
   POP3 server intends to respond with a negative status indicator, the
   POP3 server must release the lock prior to rejecting the command.)
   After returning a negative status indicator, the server may close the
   connection.  If the server does not close the connection, the client
   may either issue a new authentication command and start again, or the
   client may issue the QUIT command.
   After the POP3 server has opened the maildrop, it assigns a message-
   number to each message, and notes the size of each message in octets.
   The first message in the maildrop is assigned a message-number of
   "1", the second is assigned "2", and so on, so that the nth message
   in a maildrop is assigned a message-number of "n".  In POP3 commands
   and responses, all message-numbers and message sizes are expressed in
   base-10 (i.e., decimal).
   Here is the summary for the QUIT command when used in the
   AUTHORIZATION state:
      QUIT
         Arguments: none
         Restrictions: none
         Possible Responses:
             +OK
         Examples:
             C: QUIT
             S: +OK dewey POP3 server signing off
Section 6. The UPDATE State

When the client issues the QUIT command from the TRANSACTION state,
   the POP3 session enters the UPDATE state.  (Note that if the client
   issues the QUIT command from the AUTHORIZATION state, the POP3
   session terminates but does NOT enter the UPDATE state.)
   If a session terminates for some reason other than a client-issued
   QUIT command, the POP3 session does NOT enter the UPDATE state and
   MUST not remove any messages from the maildrop.
      QUIT
         Arguments: none
         Restrictions: none
         Discussion:
             The POP3 server removes all messages marked as deleted
             from the maildrop and replies as to the status of this
             operation.  If there is an error, such as a resource
             shortage, encountered while removing messages, the
             maildrop may result in having some or none of the messages
             marked as deleted be removed.  In no case may the server
             remove any messages not marked as deleted.
             Whether the removal was successful or not, the server
             then releases any exclusive-access lock on the maildrop
             and closes the TCP connection.
         Possible Responses:
             +OK
             -ERR some deleted messages not removed
         Examples:
             C: QUIT
             S: +OK dewey POP3 server signing off (maildrop empty)
                ...
             C: QUIT
             S: +OK dewey POP3 server signing off (2 messages left)
                ...
Section 9. POP3 Command Summary

Minimal POP3 Commands:
         USER name               valid in the AUTHORIZATION state
         PASS string
         QUIT
         STAT                    valid in the TRANSACTION state
         LIST [msg]
         RETR msg
         DELE msg
         NOOP
         RSET
         QUIT
      Optional POP3 Commands:
         APOP name digest        valid in the AUTHORIZATION state
         TOP msg n               valid in the TRANSACTION state
         UIDL [msg]
      POP3 Replies:
         +OK
         -ERR
      Note that with the exception of the STAT, LIST, and UIDL commands,
      the reply given by the POP3 server to any command is significant
      only to "+OK" and "-ERR".  Any text occurring after this reply
      may be ignored by the client.
Section 10. Example POP3 Session

S: <wait for connection on TCP port 110>
      C: <open connection>
      S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
      C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
      S:    +OK mrose's maildrop has 2 messages (320 octets)
      C:    STAT
      S:    +OK 2 320
      C:    LIST
      S:    +OK 2 messages (320 octets)
      S:    1 120
      S:    2 200
      S:    .
      C:    RETR 1
      S:    +OK 120 octets
      S:    <the POP3 server sends message 1>
      S:    .
      C:    DELE 1
      S:    +OK message 1 deleted
      C:    RETR 2
      S:    +OK 200 octets
      S:    <the POP3 server sends message 2>
      S:    .
      C:    DELE 2
      S:    +OK message 2 deleted
      C:    QUIT
      S:    +OK dewey POP3 server signing off (maildrop empty)
      C:  <close connection>
      S:  <wait for next connection>
Section 11. Message Format

All messages transmitted during a POP3 session are assumed to conform
   to the standard for the format of Internet text messages [RFC822].
   It is important to note that the octet count for a message on the
   server host may differ from the octet count assigned to that message
   due to local conventions for designating end-of-line.  Usually,
   during the AUTHORIZATION state of the POP3 session, the POP3 server
   can calculate the size of each message in octets when it opens the
   maildrop.  For example, if the POP3 server host internally represents
   end-of-line as a single character, then the POP3 server simply counts
   each occurrence of this character in a message as two octets.  Note
   that lines in the message which start with the termination octet need
   not (and must not) be counted twice, since the POP3 client will
   remove all byte-stuffed termination characters when it receives a
   multi-line response.
Section 12. References

[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
       821, USC/Information Sciences Institute, August 1982.
   [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
       MIT Laboratory for Computer Science, April 1992.
   [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
   [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
       Carnegie Mellon, December 1994.
Section 13. Security Considerations

It is conjectured that use of the APOP command provides origin
   identification and replay protection for a POP3 session.
   Accordingly, a POP3 server which implements both the PASS and APOP
   commands should not allow both methods of access for a given user;
   that is, for a given mailbox name, either the USER/PASS command
   sequence or the APOP command is allowed, but not both.
   Further, note that as the length of the shared secret increases, so
   does the difficulty of deriving it.
   Servers that answer -ERR to the USER command are giving potential
   attackers clues about which names are valid.
   Use of the PASS command sends passwords in the clear over the
   network.
   Use of the RETR and TOP commands sends mail in the clear over the
   network.
   Otherwise, security issues are not discussed in this memo.
Section 15. Authors' Addresses

John G. Myers
   Carnegie-Mellon University
   5000 Forbes Ave
   Pittsburgh, PA 15213
   EMail: jgm+@cmu.edu
   Marshall T. Rose
   Dover Beach Consulting, Inc.
   420 Whisman Court
   Mountain View, CA  94043-2186
   EMail: mrose@dbc.mtview.ca.us
Section Appendix A. Differences from RFC 1725

This memo is a revision to RFC 1725, a Draft Standard.  It makes the
   following changes from that document:
      - clarifies that command keywords are case insensitive.
      - specifies that servers must send "+OK" and "-ERR" in
        upper case.
      - specifies that the initial greeting is a positive response,
        instead of any string which should be a positive response.
      - clarifies behavior for unimplemented commands.
      - makes the USER and PASS commands optional.
      - clarified the set of possible responses to the USER command.
      - reverses the order of the examples in the USER and PASS
        commands, to reduce confusion.
      - clarifies that the PASS command may only be given immediately
        after a successful USER command.
      - clarified the persistence requirements of UIDs and added some
        implementation notes.
      - specifies a UID length limitation of one to 70 octets.
      - specifies a status indicator length limitation
        of 512 octets, including the CRLF.
      - clarifies that LIST with no arguments on an empty mailbox
        returns success.
      - adds a reference from the LIST command to the Message Format
        section
      - clarifies the behavior of QUIT upon failure
      - clarifies the security section to not imply the use of the
        USER command with the APOP command.
      - adds references to RFCs 1730 and 1734
      - clarifies the method by which a UA may enter mail into the
        transport system.
      - clarifies that the second argument to the TOP command is a
        number of lines.
      - changes the suggestion in the Security Considerations section
        for a server to not accept both PASS and APOP for a given user
        from a "must" to a "should".
      - adds a section on scaling and operational considerations
Section Appendix B. Command Index

APOP .......................................................   15
       DELE .......................................................    8
       LIST .......................................................    6
       NOOP .......................................................    9
       PASS .......................................................   14
       QUIT .......................................................    5
       QUIT .......................................................   10
       RETR .......................................................    8
       RSET .......................................................    9
       STAT .......................................................    6
       TOP ........................................................   11
       UIDL .......................................................   12
       USER .......................................................   13