rfc1082.txt

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

Network Working Group                                            M. Rose
Request for Comments: 1082                                           TWG
                                                           November 1988



                    Post Office Protocol - Version 3
                       Extended Service Offerings

Status of This Memo

   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 -  Version 3 (POP3).
   This RFC specifies a proposed protocol for the Internet community,
   and requests discussion and suggestions for improvements.  All of the
   extensions described in this memo to the POP3 are OPTIONAL.
   Distribution of this memo is unlimited.

Introduction and Motivation

   It is assumed that the reader is familiar with RFC 1081 that
   discusses the Post Office Protocol - Version 3 (POP3) [RFC1081].
   This memo describes extensions to the POP3 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 POP3 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












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


       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 [RFC1081], 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 [RFC1081], 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 POP3 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 POP3 defined in [RFC1081] are presented.  Finally,
   some additional policy details are discussed along with some initial
   experiences.





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


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, a 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 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



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


   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]):












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


         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: [e-mail]

         REQUEST         Meaning: the primary moderator of the group
                         Syntax:  822 address
                         Example: [e-mail]

         FLAGS           Meaning: locally meaningful flags associated
                                  with the discussion group; this memo
                                  leaves interpretation of this
                                  parameter to each POP3 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.





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


   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
   POP3.  This implies that the POP3 server has already opened the
   user's maildrop (which may be empty).  This maildrop is called the
   "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).