popbb.txt

早期freebsd实现

Request For Comments:  draft












		      Post Office Protocol (revised)
			Extended Service Offerings


			 Wed Dec 18 23:17:52 1985


			     Marshall T. Rose

		 Northrop Research and Technology Center
			    One Research Park
		    Palos Verdes Peninsula, CA  90274

			    MRose%NRTC@USC-ECL




    This memo suggests a simple method for workstations to dynamically
    access mail from a discussion group server, as an extension to an
    earlier memo which dealt with dynamically accessing mail from a
    mailbox server using the Post Office Protocol (POP).  This RFC
    specifies a proposed protocol for the ARPA Internet community, and
    requests discussion and suggestions for improvements.  All of the
    extensions described in this memo to the POP are OPTIONAL.  

Request For Comments:  draft 					 M. Rose
POP (revised) Extended Service Offerings			    NRTC



		       Introduction and Motivation

    It is assumed that the reader is familiar with the previous memo
    that discusses the Post Office Protocol (POP) [MRose84].  This memo
    describes extensions to the POP which enhance the service it offers
    to clients.  This additional service permits a client host to access
    discussion group mail, which is often kept in a separate spool area,
    using the general POP facilities.  

    The next section describes the evolution of discussion groups and
    the technologies currently used to implement them.  To summarize:

	o An exploder is used to map from a single address to
	  a list of addresses which subscribe to the list, and redirects
	  any subsequent error reports associated with the delivery of
	  each message.  This has two primary advantages:
		- Subscribers need know only a single address
		- Responsible parties get the error reports and not
		  the subscribers

	o Typically, each subscription address is not a person's private
	  maildrop, but a system-wide maildrop, which can be accessed
	  by more than one user.  This has several advantages:
		- Only a single copy of each message need traverse the
		  net for a given site (which may contain several local
		  hosts).  This conserves bandwidth and cycles.
		- Only a single copy of each message need reside on each
		  subscribing host.  This conserves disk space.
		- The private maildrop for each user is not cluttered
		  with discussion group mail.

    Despite this optimization of resources, further economy can be
    achieved at sites with more than one host.  Typically, sites with
    more than one host either:

	 1.  Replicate discussion group mail on each host.  This
	 results in literally gigabytes of disk space committed to
	 unnecessarily store redundant information.

	 2.  Keep discussion group mail on one host and give all users a
	 login on that host (in addition to any other logins they may
	 have).  This is usually a gross inconvenience for users who
	 work on other hosts, or a burden to users who are forced to
	 work on that host.  

    As discussed in [MRose84], the problem of giving workstations
    dynamic access to mail from a mailbox server has been explored in
    great detail (originally there was [RFC918], this prompted the
    author to write [MRose84], independently of this [RFC918] was
    upgraded to [RFC937]).  A natural solution to the problem outlined
    above is to keep discussion group mail on a mailbox server at each
    site and permit different hosts at that site to employ the POP to
    access discussion group mail.  If implemented properly, this
    avoids the problems of both strategies outlined above.

	ASIDE:	   It might be noted that a good distributed filesystem
		   could also solve this problem.  Sadly, "good"
		   distributed filesystems, which do not suffer
		   unacceptable response time for interactive use, are
		   few and far between these days!  

    Given this motivation, now let's consider discussion groups, both in
    general and from the point of view of a user agent.  Following this,
    extensions to the POP defined in [MRose84] are presented.  Finally,
    some additional policy details are discussed along with some initial
    experiences.

		       What's in a Discussion Group

    Since mailers and user agents first crawled out of the primordial
    ARPAnet, the value of discussion groups have been appreciated,
    (though their implementation has not always been well-understood).

    Described simply, an discussion group is composed of a number of
    subscribers with a common interest.  These subscribers post mail to
    a single address, known as a distribution address.  From this
    distribution address, a copy of the message is sent to each
    subscriber.  Each group has a moderator, which is the person that
    administrates the group.  The moderator can usually be reached at a
    special address, known as a request address.  Usually, the
    responsibilities of the moderator are quite simple, since the mail
    system handles the distribution to subscribers automatically.  In
    some cases, the interest group, instead of being distributed
    directly to its subscribers, is put into a digest format by the
    moderator and then sent to the subscribers.  Although this requires
    more work on the part of the moderator, such groups tend to be
    better organized.  

    Unfortunately, there are a few problems with the scheme outlined
    above.  First, if two users on the same host subscribe to the same
    interest group, two copies of the message get delivered.  This is
    wasteful of both processor and disk resources.  

    Second, some of these groups carry a lot of traffic.  Although
    subscription to an group does indicate interest on the part of a
    subscriber, it is usually not interesting to get 50 messages or so
    delivered to the user's private maildrop each day, interspersed with
    personal mail, that is likely to be of a much more important and
    timely nature.  

    Third, if a subscriber on the distribution list for a group becomes
    "bad" somehow, the originator of the message and not the moderator
    of the group is notified.  It is not uncommon for a large list to
    have 10 or so bogus addresses present.  This results in the
    originator being flooded with "error messages" from mailers across
    the ARPA Internet stating that a given address on the list was bad.
    Needless to say, the originator usually could not care less if the
    bogus addresses got a copy of the message or not.  The originator is
    merely interested in posting a message to the group at large.
    Furthermore, the moderator of the group does care if there are bogus
    addresses on the list, but ironically does not receive notification.

    There are various approaches which can be used to solve some or all
    of these problems.  Usually these involve placing an exploder agent
    at the distribution source of the discussion group, which expands
    the name of the group into the list of subscription addresses for
    the group.  In the process, the exploder will also change the
    address that receives error notifications to be the request address
    or other responsible party.  

    A complementary approach, used in order to cut down on resource
    utilization of all kinds, replaces all the subscribers at a single
    host (or group of hosts under a single administration) with a single
    address at that host.  This address maps to a file on the host,
    usually in a spool area, which all users can access.  (Advanced
    implementations can also implement private discussion groups this
    way, in which a single copy of each message is kept, but is
    accessible to only a select number of users on the host.)  

    The two approaches can be combined to avoid all of the problems
    described above.

    Finally, a third approach can be taken, which can be used to aid
    user agents processing mail for the discussion group:  In order to
    speed querying of the maildrop which contains the local host's copy
    of the discussion group, two other items are usually associated with
    the discussion group, on a local basis.  These are the maxima and
    the last-date.  Each time a message is received for the group on the
    local host, the maxima is increased by at least one.  Furthermore,
    when a new maxima is generated, the current date is determined.
    This is called the last date.  As the message is entered into the
    local maildrop, it is given the current maxima and last-date.  This
    permits the user agent to quickly determine if new messages are
    present in the maildrop.

	NOTE:	   The maxima may be characterized as a monotonically
		   increasing quanity.  Although sucessive values of the
		   maxima need not be consecutive, any maxima assigned
		   is always greater than any previously assigned value.

			   Definition of Terms

    To formalize these notions somewhat, consider the following 7
    parameters which describe a given discussion group from the
    perspective of the user agent (the syntax given is from [RFC822]):

	NAME		Meaning: the name of the discussion group
			Syntax:  TOKEN (ALPHA *[ ALPHA / DIGIT / "-" ])
				 (case-insensitive recognition)
			Example: unix-wizards

	ALIASES		Meaning: alternates names for the group, which
				 are locally meaningful; these are
				 typically used to shorten user typein
			Syntax:  TOKEN (case-insensitive recognition)
			Example: uwiz

	ADDRESS		Meaning: the primary source of the group
			Syntax:  822 address
			Example: Unix-Wizards@BRL

	REQUEST		Meaning: the primary moderator of the group
			Syntax:  822 address
			Example: Unix-Wizards-Request@BRL

	FLAGS		Meaning: locally meaningful flags associated
				 with the discussion group; this memo
				 leaves interpretation of this parameter
				 to each POP implementation
			Syntax:	 octal number
			Example: 01

	MAXIMA		Meaning: the magic cookie associated with the
				 last message locally received for the
				 group; it is the property of the magic
				 cookie that it's value NEVER decreases,
				 and increases by at least one each time
				 a message is locally received
			Syntax:	 decimal number
			Example: 1004

	LASTDATE	Meaning: the date that the last message was
				 locally received
			Syntax:  822 date
			Example: Thu, 19 Dec 85 10:26:48 -0800

    Note that the last two values are locally determined for the
    maildrop associated with the discussion group and with each message
    in that maildrop.  Note however that the last message in the
    maildrop have a different MAXIMA and LASTDATE than the discussion
    group.  This often occurs when the maildrop has been archived.

    Finally, some local systems provide mechanisms for automatically
    archiving discussion group mail.  In some cases, a two-level archive
    scheme is used:  current mail is kept in the standard maildrop,
    recent mail is kept in an archive maildrop, and older mail is kept
    off-line.  With this scheme, in addition to having a "standard"
    maildrop for each discussion group, an "archive" maildrop may also
    be available.  This permits a user agent to examine the most recent
    archive using the same mechanisms as those used on the current mail.

			     The XTND Command

    The following commands are valid only in the TRANSACTION state of
    the POP.  This implies that the POP server has already opened the
    user's maildrop (which may be empty).  This maildrop is called the