419.htm

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

   *  Imposing a per-user maildrop storage quota or the like. <br>
      A disadvantage to this option is that accumulation of messages may <br>
      result in the user's inability to receive new ones into the <br>
      maildrop.  Sites which choose this option should be sure to inform <br>
      users of impending or current exhaustion of quota, perhaps by <br>
      inserting an appropriate message into the user's maildrop. <br>
   *  Enforce a site policy regarding mail retention on the server. <br>
      Sites are free to establish local policy regarding the storage and <br>
      retention of messages on the server, both read and unread.  For <br>
      example, a site might delete unread messages from the server after <br>

      60 days and delete read messages after 7 days.  Such message <br>
      deletions are outside the scope of the POP3 protocol and are not <br>
      considered a protocol violation. <br>
      Server operators enforcing message deletion policies should take <br>
      care to make all users aware of the policies in force. <br>
      Clients must not assume that a site policy will automate message <br>
      deletions, and should continue to explicitly delete messages using <br>
      the DELE command when appropriate. <br>
      It should be noted that enforcing site message deletion policies <br>
      may be confusing to the user community, since their POP3 client <br>
      may contain configuration options to leave mail on the server <br>
      which will not in fact be supported by the server. <br>
      One special case of a site policy is that messages may only be <br>
      downloaded once from the server, and are deleted after this has <br>
      been accomplished.  This could be implemented in POP3 server <br>
Myers & Rose                Standards Track                    [Page 17] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
      software by the following mechanism: "following a POP3 login by a <br>
      client which was ended by a QUIT, delete all messages downloaded <br>
      during the session with the RETR command".  It is important not to <br>
      delete messages in the event of abnormal connection termination <br>

      (ie, if no QUIT was received from the client) because the client <br>
      may not have successfully received or stored the messages. <br>
      Servers implementing a download-and-delete policy may also wish to <br>
      disable or limit the optional TOP command, since it could be used <br>
      as an alternate mechanism to download entire messages. <br>
9. POP3 Command Summary <br>
      Minimal POP3 Commands: <br>
         USER name               valid in the AUTHORIZATION state <br>
         PASS string <br>
         QUIT <br>
         STAT                    valid in the TRANSACTION state <br>
         LIST [msg] <br>
         RETR msg <br>
         DELE msg <br>
         NOOP <br>
         RSET <br>
         QUIT <br>
      Optional POP3 Commands: <br>
         APOP name digest        valid in the AUTHORIZATION state <br>
         TOP msg n               valid in the TRANSACTION state <br>
         UIDL [msg] <br>
      POP3 Replies: <br>

         +OK <br>
         -ERR <br>
      Note that with the exception of the STAT, LIST, and UIDL commands, <br>
      the reply given by the POP3 server to any command is significant <br>
      only to "+OK" and "-ERR".  Any text occurring after this reply <br>
      may be ignored by the client. <br>
Myers & Rose                Standards Track                    [Page 18] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
10. Example POP3 Session <br>
      S: <wait for connection on TCP port 110> <br>
      C: <open connection> <br>
      S:    +OK POP3 server ready <[e-mail]> <br>
      C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb <br>
      S:    +OK mrose's maildrop has 2 messages (320 octets) <br>
      C:    STAT <br>
      S:    +OK 2 320 <br>
      C:    LIST <br>
      S:    +OK 2 messages (320 octets) <br>
      S:    1 120 <br>
      S:    2 200 <br>
      S:    . <br>
      S:    . <br>
      C:    RETR 1 <br>
      S:    +OK 120 octets <br>
      S:    <the POP3 server sends message 1> <br>
      S:    . <br>
      C:    DELE 1 <br>
      S:    +OK message 1 deleted <br>
      C:    RETR 2 <br>
      S:    +OK 200 octets <br>
      S:    <the POP3 server sends message 2> <br>
      S:    . <br>
      C:    DELE 2 <br>
      S:    +OK message 2 deleted <br>
      C:    QUIT <br>
      S:    +OK dewey POP3 server signing off (maildrop empty) <br>
      C:  <close connection> <br>
      S:  <wait for next connection> <br>
11. Message Format <br>
   All messages transmitted during a POP3 session are assumed to conform <br>
   to the standard for the format of Internet text messages [RFC822]. <br>
   It is important to note that the octet count for a message on the <br>
   server host may differ from the octet count assigned to that message <br>
   due to local conventions for designating end-of-line.  Usually, <br>

   during the AUTHORIZATION state of the POP3 session, the POP3 server <br>
   can calculate the size of each message in octets when it opens the <br>
   maildrop.  For example, if the POP3 server host internally represents <br>
   end-of-line as a single character, then the POP3 server simply counts <br>
   each occurrence of this character in a message as two octets.  Note <br>
   that lines in the message which start with the termination octet need <br>
   not (and must not) be counted twice, since the POP3 client will <br>
   remove all byte-stuffed termination characters when it receives a <br>
   multi-line response. <br>
Myers & Rose                Standards Track                    [Page 19] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
12. References <br>
   [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC <br>
       821, USC/Information Sciences Institute, August 1982. <br>
   [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text <br>
       Messages", STD 11, RFC 822, University of Delaware, August 1982. <br>
   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, <br>
       MIT Laboratory for Computer Science, April 1992. <br>
   [RFC1730] Crispin, M., "Internet Message Access Protocol - Version <br>
       4", RFC 1730, University of Washington, December 1994. <br>
   [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, <br>

       Carnegie Mellon, December 1994. <br>
13. Security Considerations <br>
   It is conjectured that use of the APOP command provides origin <br>
   identification and replay protection for a POP3 session. <br>
   Accordingly, a POP3 server which implements both the PASS and APOP <br>
   commands should not allow both methods of access for a given user; <br>
   that is, for a given mailbox name, either the USER/PASS command <br>
   sequence or the APOP command is allowed, but not both. <br>
   Further, note that as the length of the shared secret increases, so <br>
   does the difficulty of deriving it. <br>
   Servers that answer -ERR to the USER command are giving potential <br>
   attackers clues about which names are valid. <br>
   Use of the PASS command sends passwords in the clear over the <br>
   network. <br>
   Use of the RETR and TOP commands sends mail in the clear over the <br>
   network. <br>
   Otherwise, security issues are not discussed in this memo. <br>
14. Acknowledgements <br>
   The POP family has a long and checkered history.  Although primarily <br>
   a minor revision to RFC 1460, POP3 is based on the ideas presented in <br>
   RFCs 918, 937, and 1081. <br>
   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff <br>

   provided significant comments on the APOP command. <br>
Myers & Rose                Standards Track                    [Page 20] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
15. Authors' Addresses <br>
   John G. Myers <br>
   Carnegie-Mellon University <br>
   5000 Forbes Ave <br>
   Pittsburgh, PA 15213 <br>
   EMail: [e-mail] <br>
   Marshall T. Rose <br>
   Dover Beach Consulting, Inc. <br>
   420 Whisman Court <br>
   Mountain View, CA  94043-2186 <br>
   EMail: [e-mail] <br>
Myers & Rose                Standards Track                    [Page 21] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
Appendix A. Differences from RFC 1725 <br>
   This memo is a revision to RFC 1725, a Draft Standard.  It makes the <br>
   following changes from that document: <br>
      - clarifies that command keywords are case insensitive. <br>

      - specifies that servers must send "+OK" and "-ERR" in <br>
        upper case. <br>
      - specifies that the initial greeting is a positive response, <br>
        instead of any string which should be a positive response. <br>
      - clarifies behavior for unimplemented commands. <br>
      - makes the USER and PASS commands optional. <br>
      - clarified the set of possible responses to the USER command. <br>
      - reverses the order of the examples in the USER and PASS <br>
        commands, to reduce confusion. <br>
      - clarifies that the PASS command may only be given immediately <br>
        after a successful USER command. <br>
      - clarified the persistence requirements of UIDs and added some <br>
        implementation notes. <br>
      - specifies a UID length limitation of one to 70 octets. <br>
      - specifies a status indicator length limitation <br>
        of 512 octets, including the CRLF. <br>
      - clarifies that LIST with no arguments on an empty mailbox <br>
        returns success. <br>
      - adds a reference from the LIST command to the Message Format <br>
        section <br>
      - clarifies the behavior of QUIT upon failure <br>
      - clarifies the security section to not imply the use of the <br>

        USER command with the APOP command. <br>
      - adds references to RFCs 1730 and 1734 <br>
      - clarifies the method by which a UA may enter mail into the <br>
        transport system. <br>
Myers & Rose                Standards Track                    [Page 22] <br>
  <br>
RFC 1939                          POP3                          May 1996 <br>
      - clarifies that the second argument to the TOP command is a <br>
        number of lines. <br>
      - changes the suggestion in the Security Considerations section <br>
        for a server to not accept both PASS and APOP for a given user <br>
        from a "must" to a "should". <br>
      - adds a section on scaling and operational considerations <br>
Appendix B. Command Index <br>
       APOP .......................................................   15 <br>
       DELE .......................................................    8 <br>
       LIST .......................................................    6 <br>
       NOOP .......................................................    9 <br>
       PASS .......................................................   14 <br>
       QUIT .......................................................    5 <br>
       QUIT .......................................................   10 <br>
       RETR .......................................................    8 <br>

       RSET .......................................................    9 <br>
       STAT .......................................................    6 <br>
       TOP ........................................................   11 <br>
       UIDL .......................................................   12 <br>
       USER .......................................................   13 <br>
Myers & Rose                Standards Track                    [Page 23] <br>
  <br>
  <br>
  <br>
  <br>
-- <br>
指点江山，激扬文字，粪土当年万户侯。 <br>
  <br>
  <br>
※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.161.69] <br>
</small><hr>
<p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="398.htm">上一层</a>][<a href="420.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>