419.htm

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

         Examples: <br>
             C: TOP 1 10 <br>
             S: +OK <br>
Myers & Rose                Standards Track                    [Page 11] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
             S: <the POP3 server sends the headers of the <br>
                message, a blank line, and the first 10 lines <br>
                of the body of the message> <br>
             S: . <br>
                ... <br>
             C: TOP 100 3 <br>
             S: -ERR no such message <br>
      UIDL [msg] <br>
      Arguments: <br>
          a message-number (optional), which, if present, may NOT <br>
          refer to a message marked as deleted <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 positive <br>
          response with a line containing information for that message. <br>
          This line is called a "unique-id listing" for that message. <br>
          If no argument was given and the POP3 server issues a positive <br>
          response, then the response given is multi-line.  After the <br>
          initial +OK, for each message in the maildrop, the POP3 server <br>
          responds with a line containing information for that message. <br>
          This line is called a "unique-id listing" for that message. <br>
          In order to simplify parsing, all POP3 servers are required to <br>
          use a certain format for unique-id listings.  A unique-id <br>
          listing consists of the message-number of the message, <br>
          followed by a single space and the unique-id of the message. <br>
          No information follows the unique-id in the unique-id listing. <br>
          The unique-id of a message is an arbitrary server-determined <br>
          string, consisting of one to 70 characters in the range 0x21 <br>
          to 0x7E, which uniquely identifies a message within a <br>
          maildrop and which persists across sessions.  This <br>
          persistence is required even if a session ends without <br>
          entering the UPDATE state.  The server should never reuse an <br>
          unique-id in a given maildrop, for as long as the entity <br>
          using the unique-id exists. <br>

          Note that messages marked as deleted are not listed. <br>
          While it is generally preferable for server implementations <br>
          to store arbitrarily assigned unique-ids in the maildrop, <br>
Myers & Rose                Standards Track                    [Page 12] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
          this specification is intended to permit unique-ids to be <br>
          calculated as a hash of the message.  Clients should be able <br>
          to handle a situation where two identical copies of a <br>
          message in a maildrop have the same unique-id. <br>
      Possible Responses: <br>
          +OK unique-id listing follows <br>
          -ERR no such message <br>
      Examples: <br>
          C: UIDL <br>
          S: +OK <br>
          S: 1 whqtswO00WBw418f9t5JxYwZ <br>
          S: 2 QhdPYR:00WBw1Ph7x7 <br>
          S: . <br>
             ... <br>
          C: UIDL 2 <br>
          S: +OK 2 QhdPYR:00WBw1Ph7x7 <br>

             ... <br>
          C: UIDL 3 <br>
          S: -ERR no such message, only 2 messages in maildrop <br>
      USER name <br>
         Arguments: <br>
             a string identifying a mailbox (required), which is of <br>
             significance ONLY to the server <br>
         Restrictions: <br>
             may only be given in the AUTHORIZATION state after the POP3 <br>
             greeting or after an unsuccessful USER or PASS command <br>
         Discussion: <br>
             To authenticate using the USER and PASS command <br>
             combination, the client must first issue the USER <br>
             command.  If the POP3 server responds with a positive <br>
             status indicator ("+OK"), then the client may issue <br>
             either the PASS command to complete the authentication, <br>
             or the QUIT command to terminate the POP3 session.  If <br>
             the POP3 server responds with a negative status indicator <br>
             ("-ERR") to the USER command, then the client may either <br>
             issue a new authentication command or may issue the QUIT <br>
             command. <br>
             The server may return a positive response even though no <br>

             such mailbox exists.  The server may return a negative <br>
             response if mailbox exists, but does not permit plaintext <br>
Myers & Rose                Standards Track                    [Page 13] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
             password authentication. <br>
         Possible Responses: <br>
             +OK name is a valid mailbox <br>
             -ERR never heard of mailbox name <br>
         Examples: <br>
             C: USER frated <br>
             S: -ERR sorry, no mailbox for frated here <br>
                ... <br>
             C: USER mrose <br>
             S: +OK mrose is a real hoopy frood <br>
      PASS string <br>
         Arguments: <br>
             a server/mailbox-specific password (required) <br>
         Restrictions: <br>
             may only be given in the AUTHORIZATION state immediately <br>
             after a successful USER command <br>
         Discussion: <br>

             When the client issues the PASS command, the POP3 server <br>
             uses the argument pair from the USER and PASS commands to <br>
             determine if the client should be given access to the <br>
             appropriate maildrop. <br>
  <br>
             Since the PASS command has exactly one argument, a POP3 <br>
             server may treat spaces in the argument as part of the <br>
             password, instead of as argument separators. <br>
         Possible Responses: <br>
             +OK maildrop locked and ready <br>
             -ERR invalid password <br>
             -ERR unable to lock maildrop <br>
         Examples: <br>
             C: USER mrose <br>
             S: +OK mrose is a real hoopy frood <br>
             C: PASS secret <br>
             S: -ERR maildrop already locked <br>
               ... <br>
             C: USER mrose <br>
             S: +OK mrose is a real hoopy frood <br>
             C: PASS secret <br>
             S: +OK mrose's maildrop has 2 messages (320 octets) <br>

Myers & Rose                Standards Track                    [Page 14] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
      APOP name digest <br>
         Arguments: <br>
             a string identifying a mailbox and a MD5 digest string <br>
             (both required) <br>
         Restrictions: <br>
             may only be given in the AUTHORIZATION state after the POP3 <br>
             greeting or after an unsuccessful USER or PASS command <br>
         Discussion: <br>
             Normally, each POP3 session starts with a USER/PASS <br>
             exchange.  This results in a server/user-id specific <br>
             password being sent in the clear on the network.  For <br>
             intermittent use of POP3, this may not introduce a sizable <br>
             risk.  However, many POP3 client implementations connect to <br>
             the POP3 server on a regular basis -- to check for new <br>
             mail.  Further the interval of session initiation may be on <br>
             the order of five minutes.  Hence, the risk of password <br>
             capture is greatly enhanced. <br>
             An alternate method of authentication is required which <br>
             provides for both origin authentication and replay <br>

             protection, but which does not involve sending a password <br>
             in the clear over the network.  The APOP command provides <br>
             this functionality. <br>
             A POP3 server which implements the APOP command will <br>
             include a timestamp in its banner greeting.  The syntax of <br>
             the timestamp corresponds to the `msg-id' in [RFC822], and <br>
             MUST be different each time the POP3 server issues a banner <br>
             greeting.  For example, on a UNIX implementation in which a <br>
             separate UNIX process is used for each instance of a POP3 <br>
             server, the syntax of the timestamp might be: <br>
                <process-ID.clock@hostname> <br>
             where `process-ID' is the decimal value of the process's <br>
             PID, clock is the decimal value of the system clock, and <br>
             hostname is the fully-qualified domain-name corresponding <br>
             to the host where the POP3 server is running. <br>
             The POP3 client makes note of this timestamp, and then <br>
             issues the APOP command.  The `name' parameter has <br>
             identical semantics to the `name' parameter of the USER <br>
             command. The `digest' parameter is calculated by applying <br>
             the MD5 algorithm [RFC1321] to a string consisting of the <br>
             timestamp (including angle-brackets) followed by a shared <br>
Myers & Rose                Standards Track                    [Page 15] <br>

  <br>
RFC 1939                          POP3                          May 1996 <br>
             secret.  This shared secret is a string known only to the <br>
             POP3 client and server.  Great care should be taken to <br>
             prevent unauthorized disclosure of the secret, as knowledge <br>
             of the secret will allow any entity to successfully <br>
             masquerade as the named user.  The `digest' parameter <br>
             itself is a 16-octet value which is sent in hexadecimal <br>
             format, using lower-case ASCII characters. <br>
             When the POP3 server receives the APOP command, it verifies <br>
             the digest provided.  If the digest is correct, the POP3 <br>
             server issues a positive response, and the POP3 session <br>
             enters the TRANSACTION state.  Otherwise, a negative <br>
             response is issued and the POP3 session remains in the <br>
             AUTHORIZATION state. <br>
             Note that as the length of the shared secret increases, so <br>
             does the difficulty of deriving it.  As such, shared <br>
             secrets should be long strings (considerably longer than <br>
             the 8-character example shown below). <br>
         Possible Responses: <br>
             +OK maildrop locked and ready <br>
             -ERR permission denied <br>

         Examples: <br>
             S: +OK POP3 server ready <[e-mail]> <br>
             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb <br>
             S: +OK maildrop has 1 message (369 octets) <br>
             In this example, the shared  secret  is  the  string  `tan- <br>
             staaf'.  Hence, the MD5 algorithm is applied to the string <br>
                <[e-mail]>tanstaaf <br>
             which produces a digest value of <br>
                c4c9334bac560ecc979e58001b3e22fb <br>
8. Scaling and Operational Considerations <br>
   Since some of the optional features described above were added to the <br>
   POP3 protocol, experience has accumulated in using them in large- <br>
   scale commercial post office operations where most of the users are <br>
   unrelated to each other.  In these situations and others, users and <br>
   vendors of POP3 clients have discovered that the combination of using <br>
   the UIDL command and not issuing the DELE command can provide a weak <br>
   version of the "maildrop as semi-permanent repository" functionality <br>
   normally associated with IMAP.  Of course the other capabilities of <br>
Myers & Rose                Standards Track                    [Page 16] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
   IMAP, such as polling an existing connection for newly arrived <br>

   messages and supporting multiple folders on the server, are not <br>
   present in POP3. <br>
   When these facilities are used in this way by casual users, there has <br>
   been a tendency for already-read messages to accumulate on the server <br>
   without bound.  This is clearly an undesirable behavior pattern from <br>
   the standpoint of the server operator.  This situation is aggravated <br>
   by the fact that the limited capabilities of the POP3 do not permit <br>
   efficient handling of maildrops which have hundreds or thousands of <br>
   messages. <br>
   Consequently, it is recommended that operators of large-scale multi- <br>
   user servers, especially ones in which the user's only access to the <br>
   maildrop is via POP3, consider such options as: <br>