rfc1082.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   In the latter context, a maildrop associated with a discussion group
   is considered to be read-only to the POP3 client.  In this case, the
   phrase "closes the current maildrop" merely means that any
   implementation-specific resources are released.  (Hence, the POP3
   command DELE is a no-op.)

   All the new facilities are introduced via a single POP3 command,
   XTND.  All positive reponses to the XTND command are multi-line.

   The most common multi-line response to the commands contains a
   "discussion group listing" which presents the name of the discussion
   group along with it's maxima.  In order to simplify parsing all POP3
   servers are required to use a certain format for discussion group
   listings:

                              NAME SP MAXIMA

   This memo makes no requirement on what follows the maxima in the
   listing.  Minimal implementations should just end that line of the
   response with a CRLF pair.  More advanced implementations may include
   other information, as parsed from the message.

       NOTE:      This memo STRONGLY discourages implementations from
                  supplying additional information in the listing.



Rose                                                            [Page 6]

RFC 1082                 POP3 Extended Service             November 1988


   XTND BBOARDS [name]
   Arguments: the name of a discussion group (optionally)
   Restrictions: may only be given in the TRANSACTION state.
   Discussion:

   If an argument was given, the POP3 server closes the current
   maildrop.  The POP3 server then validates the argument as the name of
   a discussion group.  If this is successful, it opens the maildrop
   associated with the group, and returns a multi-line response
   containing the discussion group listing.  If the discussion group
   named is not valid, or the associated archive maildrop is not
   readable by the user, then an error response is returned.

   If no argument was given, the POP3 server issues a multi-line
   response.  After the initial +OK, for each discussion group known,
   the POP3 server responds with a line containing the listing for that
   discussion group.  Note that only world-readable discussion groups
   are included in the multi-line response.

   In order to aid user agents, this memo requires an extension to the
   scan listing when an "XTND BBOARDS" command has been given.
   Normally, a scan listing, as generated by the LIST, takes the form:

          MSGNO SIZE

   where MSGNO is the number of the message being listed and SIZE is the
   size of the message in octets.  When reading a maildrop accessed via
   "XTND BBOARDS", the scan listing takes the form

          MSGNO SIZE MAXIMA

   where MAXIMA is the maxima that was assigned to the message when it
   was placed in the BBoard.

   Possible Responses:
       +OK XTND
       -ERR no such bboard
   Examples:
       C:    XTND BBOARDS
       S:    +OK XTND
       S:    system 10
       S:    mh-users 100
       S:    .
       C:    XTND BBOARDS system
       S:    + OK XTND
       S:    system 10
       S:    .




Rose                                                            [Page 7]

RFC 1082                 POP3 Extended Service             November 1988


   XTND ARCHIVE name
   Arguments: the name of a discussion group (required)
   Restrictions: may only be given in the TRANSACTION state.
   Discussion:

   The POP3 server closes the current maildrop.  The POP3 server then
   validates the argument as the name of a discussion group.  If this is
   successful, it opens the archive maildrop associated with the group,
   and returns a multi-line response containing the discussion group
   listing.  If the discussion group named is not valid, or the
   associated archive maildrop is not readable by the user, then an
   error response is returned.

   In addition, the scan listing generated by the LIST command is
   augmented (as described above).

   Possible Responses:
       +OK XTND
       -ERR no such bboard Examples:
       C:    XTND ARCHIVE system
       S:    + OK XTND
       S:    system 3
       S:    .

   XTND X-BBOARDS name
   Arguments: the name of a discussion group (required)
   Restrictions: may only be given in the TRANSACTION state.
   Discussion:

   The POP3 server validates the argument as the name of a
   discussion group.  If this is unsuccessful, then an error
   response is returned.  Otherwise a multi-line response is
   returned.  The first 14 lines of this response (after the
   initial +OK) are defined in this memo.  Minimal implementations
   need not include other information (and may omit certain
   information, outputing a bare CRLF pair).  More advanced
   implementations may include other information.

           Line    Information (refer to "Definition of Terms")
           ----    -----------
             1     NAME
             2     ALIASES, separated by SP
             3     system-specific: maildrop
             4     system-specific: archive maildrop
             5     system-specific: information
             6     system-specific: maildrop map
             7     system-specific: encrypted password
             8     system-specific: local leaders, separated by SP



Rose                                                            [Page 8]

RFC 1082                 POP3 Extended Service             November 1988


             9     ADDRESS
            10     REQUEST
            11     system-specific: incoming feed
            12     system-specific: outgoing feeds
            13     FLAGS SP MAXIMA
            14     LASTDATE

   Most of this information is entirely too specific to the UCI Version
   of the Rand MH Message Handling System [MRose85].  Nevertheless,
   lines 1, 2, 9, 10, 13, and 14 are of general interest, regardless of
   the implementation.

           Possible Responses:
               +OK XTND
               -ERR no such bboard
           Examples:
               C:    XTND X-BBOARDS system
               S:    + OK XTND
               S:    system
               S:    local general
               S:    /usr/bboards/system.mbox
               S:    /usr/bboards/archive/system.mbox
               S:    /usr/bboards/.system.cnt
               S:    /usr/bboards/.system.map
               S:    *
               S:    mother
               S:    [e-mail]
               S:    [e-mail]
               S:
               S:    [e-mail]
               S:    01 10
               S:    Thu, 19 Dec 85 00:08:49 -0800
               S:    .

Policy Notes

   Depending on the particular entity administrating the POP3 service
   host, two additional policies might be implemented:

   1.  Private Discussion Groups

   In the general case, discussion groups are world-readable, any user,
   once logged in (via a terminal, terminal server, or POP3, etc.), is
   able to read the maildrop for each discussion group known to the POP3
   service host.  Nevertheless, it is desirable, usually for privacy
   reasons, to implement private discussion groups as well.

   Support of this is consistent with the extensions outlined in this



Rose                                                            [Page 9]

RFC 1082                 POP3 Extended Service             November 1988


   memo.  Once the AUTHORIZATION state has successfully concluded, the
   POP3 server grants the user access to exactly those discussion groups
   the POP3 service host permits the authenticated user to access.  As a
   "security" feature, discussion groups associated with unreadable
   maildrops should not be listed in a positive response to the XTND
   BBOARDS command.

   2.  Anonymous POP3 Users

   In order to minimize the authentication problem, a policy permitting
   "anonymous" access to the world-readable maildrops for discussion
   groups on the POP3 server may be implemented.

   Support of this is consistent with the extensions outlined in this
   memo.  The POP3 server can be modified to accept a USER command for a
   well-known pseudonym (i.e., "anonymous") which is valid with any PASS
   command.  As a "security" feature, it is advisable to limit this kind
   of access to only hosts at the local site, or to hosts named in an
   access list.

Experiences and Conclusions

   All of the facilities described in this memo and in [RFC1081] have
   been implemented in MH #6.1.  Initial experiences have been, on the
   whole, very positive.

   After the first implementation, some performance tuning was required.
   This consisted primarily of caching the datastructures which describe
   discussion groups in the POP3 server.  A second optimization
   pertained to the client:  the program most commonly used to read
   BBoards in MH was modified to retrieve messages only when needed.
   Two schemes are used:

         o If only the headers (and the first few lines of the body) of
           the message are required (e.g., for a scan listing), then only
           these are retrieved.  The resulting output is then cached, on
           a per-message basis.

         o If the entire message is required, then it is retrieved intact,
            and cached locally.

   With these optimizations, response time is quite adequate when the
   POP3 server and client are connected via a high-speed local area
   network.  In fact, the author uses this mechanism to access certain
   private discussion groups over the Internet.  In this case, response
   is still good.  When a 9.6Kbps modem is inserted in the path,
   response went from good to almost tolerable (fortunately the author
   only reads a few discussion groups in this fashion).



Rose                                                           [Page 10]

RFC 1082                 POP3 Extended Service             November 1988


   To conclude: the POP3 is a good thing, not only for personal mail but
   for discussion group mail as well.


References

     [RFC1081] Rose, M., "Post Office Protocol - Verison 3 (POP3)", RFC
               1081, TWG, November 1988.

     [MRose85] Rose, M., and J. Romine, "The Rand MH Message Handling
               System: User's Manual", University of California, Irvine,
               November 1985.

     [RFC822]  Crocker, D., "Standard for the Format of ARPA-Internet
               Text Messages", RFC 822, University of Delaware, August
               1982.

     [RFC918]  Reynolds, J., "Post Office Protocol", RFC 918,
               USC/Information Sciences Institute, October 1984.

     [RFC937]  Butler, M., J. Postel, D. Chase, J. Goldberger, and J.
               Reynolds, "Post Office Protocol - Version 2", RFC 937,
               USC/Information Sciences Institute, February 1985.

Author's Address:


   Marshall Rose
   The Wollongong Group
   1129 San Antonio Rd.
   Palo Alto, California 94303

   Phone: [phone]

   Email: [e-mail]
















Rose                                                           [Page 11]