doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc1082.txt b/doc/rfc/rfc1082.txt
new file mode 100644
index 0000000..36deae5
--- /dev/null
+++ b/doc/rfc/rfc1082.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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: Unix-Wizards@BRL.MIL
+
+         REQUEST         Meaning: the primary moderator of the group
+                         Syntax:  822 address
+                         Example: Unix-Wizards-Request@BRL.MIL
+
+         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).
+
+   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:    system@nrtc.northrop.com
+               S:    system-request@nrtc.northrop.com
+               S:
+               S:    dist-system@nrtc-gremlin.northrop.com
+               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: (415) 962-7100
+
+   Email: MRose@TWG.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                                                           [Page 11]
+
\ No newline at end of file