419.htm

pcb设计资料初学者难得的入门资料包含工厂制作过程

   Here are the POP3 commands valid in the TRANSACTION state: <br>
      STAT <br>
         Arguments: none <br>
         Restrictions: <br>
             may only be given in the TRANSACTION state <br>

         Discussion: <br>
             The POP3 server issues a positive response with a line <br>
             containing information for the maildrop.  This line is <br>
             called a "drop listing" for that maildrop. <br>
             In order to simplify parsing, all POP3 servers are <br>
             required to use a certain format for drop listings.  The <br>
             positive response consists of "+OK" followed by a single <br>
             space, the number of messages in the maildrop, a single <br>
             space, and the size of the maildrop in octets.  This memo <br>
             makes no requirement on what follows the maildrop size. <br>
             Minimal implementations should just end that line of the <br>
             response with a CRLF pair.  More advanced implementations <br>
             may include other information. <br>
                NOTE: This memo STRONGLY discourages implementations <br>
                from supplying additional information in the drop <br>
                listing.  Other, optional, facilities are discussed <br>
                later on which permit the client to parse the messages <br>
                in the maildrop. <br>
             Note that messages marked as deleted are not counted in <br>
             either total. <br>
         Possible Responses: <br>
             +OK nn mm <br>

         Examples: <br>
             C: STAT <br>
             S: +OK 2 320 <br>
      LIST [msg] <br>
         Arguments: <br>
             a message-number (optional), which, if present, may NOT <br>
             refer to a message marked as deleted <br>
Myers & Rose                Standards Track                     [Page 6] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
         Restrictions: <br>
             may only be given in the TRANSACTION state <br>
         Discussion: <br>
             If an argument was given and the POP3 server issues a <br>
             positive response with a line containing information for <br>
             that message.  This line is called a "scan listing" for <br>
             that message. <br>
             If no argument was given and the POP3 server issues a <br>
             positive response, then the response given is multi-line. <br>
             After the initial +OK, for each message in the maildrop, <br>
             the POP3 server responds with a line containing <br>
             information for that message.  This line is also called a <br>

             "scan listing" for that message.  If there are no <br>
             messages in the maildrop, then the POP3 server responds <br>
             with no scan listings--it issues a positive response <br>
             followed by a line containing a termination octet and a <br>
             CRLF pair. <br>
             In order to simplify parsing, all POP3 servers are <br>
             required to use a certain format for scan listings.  A <br>
             scan listing consists of the message-number of the <br>
             message, followed by a single space and the exact size of <br>
             the message in octets.  Methods for calculating the exact <br>
             size of the message are described in the "Message Format" <br>
             section below.  This memo makes no requirement on what <br>
             follows the message size in the scan listing.  Minimal <br>
             implementations should just end that line of the response <br>
             with a CRLF pair.  More advanced implementations may <br>
             include other information, as parsed from the message. <br>
                NOTE: This memo STRONGLY discourages implementations <br>
                from supplying additional information in the scan <br>
                listing.  Other, optional, facilities are discussed <br>
                later on which permit the client to parse the messages <br>
                in the maildrop. <br>
             Note that messages marked as deleted are not listed. <br>

         Possible Responses: <br>
             +OK scan listing follows <br>
             -ERR no such message <br>
         Examples: <br>
             C: LIST <br>
             S: +OK 2 messages (320 octets) <br>
             S: 1 120 <br>
Myers & Rose                Standards Track                     [Page 7] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
             S: 2 200 <br>
             S: . <br>
               ... <br>
             C: LIST 2 <br>
             S: +OK 2 200 <br>
               ... <br>
             C: LIST 3 <br>
             S: -ERR no such message, only 2 messages in maildrop <br>
      RETR msg <br>
         Arguments: <br>
             a message-number (required) which may NOT refer to a <br>
             message marked as deleted <br>

         Restrictions: <br>
             may only be given in the TRANSACTION state <br>
         Discussion: <br>
             If the POP3 server issues a positive response, then the <br>
             response given is multi-line.  After the initial +OK, the <br>
             POP3 server sends the message corresponding to the given <br>
             message-number, being careful to byte-stuff the termination <br>
             character (as with all multi-line responses). <br>
         Possible Responses: <br>
             +OK message follows <br>
             -ERR no such message <br>
         Examples: <br>
             C: RETR 1 <br>
             S: +OK 120 octets <br>
             S: <the POP3 server sends the entire message here> <br>
             S: . <br>
      DELE msg <br>
         Arguments: <br>
             a message-number (required) which may NOT refer to a <br>
             message marked as deleted <br>
         Restrictions: <br>
             may only be given in the TRANSACTION state <br>

Myers & Rose                Standards Track                     [Page 8] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
         Discussion: <br>
             The POP3 server marks the message as deleted.  Any future <br>
             reference to the message-number associated with the message <br>
             in a POP3 command generates an error.  The POP3 server does <br>
             not actually delete the message until the POP3 session <br>
             enters the UPDATE state. <br>
         Possible Responses: <br>
             +OK message deleted <br>
             -ERR no such message <br>
         Examples: <br>
             C: DELE 1 <br>
             S: +OK message 1 deleted <br>
                ... <br>
             C: DELE 2 <br>
             S: -ERR message 2 already deleted <br>
      NOOP <br>
         Arguments: none <br>
         Restrictions: <br>
             may only be given in the TRANSACTION state <br>

         Discussion: <br>
             The POP3 server does nothing, it merely replies with a <br>
             positive response. <br>
         Possible Responses: <br>
             +OK <br>
         Examples: <br>
             C: NOOP <br>
             S: +OK <br>
      RSET <br>
         Arguments: none <br>
         Restrictions: <br>
             may only be given in the TRANSACTION state <br>
         Discussion: <br>
             If any messages have been marked as deleted by the POP3 <br>
             server, they are unmarked.  The POP3 server then replies <br>
Myers & Rose                Standards Track                     [Page 9] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
             with a positive response. <br>
         Possible Responses: <br>
             +OK <br>
         Examples: <br>

             C: RSET <br>
             S: +OK maildrop has 2 messages (320 octets) <br>
6. The UPDATE State <br>
   When the client issues the QUIT command from the TRANSACTION state, <br>
   the POP3 session enters the UPDATE state.  (Note that if the client <br>
   issues the QUIT command from the AUTHORIZATION state, the POP3 <br>
   session terminates but does NOT enter the UPDATE state.) <br>
   If a session terminates for some reason other than a client-issued <br>
   QUIT command, the POP3 session does NOT enter the UPDATE state and <br>
   MUST not remove any messages from the maildrop. <br>
      QUIT <br>
         Arguments: none <br>
         Restrictions: none <br>
         Discussion: <br>
             The POP3 server removes all messages marked as deleted <br>
             from the maildrop and replies as to the status of this <br>
             operation.  If there is an error, such as a resource <br>
             shortage, encountered while removing messages, the <br>
             maildrop may result in having some or none of the messages <br>
             marked as deleted be removed.  In no case may the server <br>
             remove any messages not marked as deleted. <br>
             Whether the removal was successful or not, the server <br>

             then releases any exclusive-access lock on the maildrop <br>
             and closes the TCP connection. <br>
         Possible Responses: <br>
             +OK <br>
             -ERR some deleted messages not removed <br>
         Examples: <br>
             C: QUIT <br>
             S: +OK dewey POP3 server signing off (maildrop empty) <br>
                ... <br>
             C: QUIT <br>
Myers & Rose                Standards Track                    [Page 10] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
             S: +OK dewey POP3 server signing off (2 messages left) <br>
                ... <br>
7. Optional POP3 Commands <br>
   The POP3 commands discussed above must be supported by all minimal <br>
   implementations of POP3 servers. <br>
   The optional POP3 commands described below permit a POP3 client <br>
   greater freedom in message handling, while preserving a simple POP3 <br>
   server implementation. <br>
      NOTE: This memo STRONGLY encourages implementations to support <br>

      these commands in lieu of developing augmented drop and scan <br>
      listings.  In short, the philosophy of this memo is to put <br>
      intelligence in the part of the POP3 client and not the POP3 <br>
      server. <br>
      TOP msg n <br>
         Arguments: <br>
             a message-number (required) which may NOT refer to to a <br>
             message marked as deleted, and a non-negative number <br>
             of lines (required) <br>
         Restrictions: <br>
             may only be given in the TRANSACTION state <br>
         Discussion: <br>
             If the POP3 server issues a positive response, then the <br>
             response given is multi-line.  After the initial +OK, the <br>
             POP3 server sends the headers of the message, the blank <br>
             line separating the headers from the body, and then the <br>
             number of lines of the indicated message's body, being <br>
             careful to byte-stuff the termination character (as with <br>
             all multi-line responses). <br>
             Note that if the number of lines requested by the POP3 <br>
             client is greater than than the number of lines in the <br>
             body, then the POP3 server sends the entire message. <br>

         Possible Responses: <br>
             +OK top of message follows <br>
             -ERR no such message <br>