popbb.txt

早期freebsd实现

    "default maildrop".  The phrase "closes the current maildrop" has
    two meanings, depending on whether the current maildrop is the
    default maildrop or is a maildrop associated with a discussion
    group. 

    In the former context, when the current maildrop is closed any
    messages marked as deleted are removed from the maildrop currently
    in use.  The exclusive-access lock on the maildrop is then released
    along with any implementation-specific resources (e.g.,
    file-descriptors).  

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

    All the new facilities are introduced via a single POP 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 POP
    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.  


    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 POP server closes the current
	 maildrop.  The POP 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 POP server issues a multi-line
	 response.  After the initial +OK, for each discussion group
	 known, the POP 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:    .

    XTND ARCHIVE name
	Arguments: the name of a discussion group (required)
	Restrictions: may only be given in the TRANSACTION state.
	Discussion:

	 The POP server closes the current maildrop.  The POP 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 POP 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
		  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:    system@nrtc
	    S:    system-request@nrtc
	    S:    
	    S:    dist-system@nrtc-gremlin
	    S:    01 10
	    S:    Thu, 19 Dec 85 00:08:49 -0800
	    S:    .

			       Policy Notes

    Depending on the particular entity administrating the POP 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 POP, etc.), is
    able to read the maildrop for each discussion group known to the POP
    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
    memo.  Once the AUTHORIZATION state has successfully concluded, the
    POP server grants the user access to exactly those discussion groups
    the POP 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 POP Users 

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

    Support of this is consistent with the extensions outlined in this
    memo.  The POP 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 [MRose84] 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 POP 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
    POP 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 ARPAnet.  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).  

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

    [MRose84]   M.T. Rose.
		"Post Office Protocol (revised)", University of Delaware.
		(October, 1984)

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

    [RFC822]	D.H. Crocker.
		"Standard for the Format of ARPA Internet Text
		Messages", University of Delaware.  (August, 1982)

    [RFC918]    J.K. Reynolds.
		"Post Office Protocol", USC/Information Sciences Institute.
		(October, 1984)

    [RFC937]    M. Butler, J.B. Postel, et. al.
		"Post Office Protocol - Version 2", USC/Information Sciences
		Institute.
		(February, 1985)