As per Relevance of the word discussion, we have this rfc below:
Network Working Group M.
Request for Comments: 1082
November 1988
Post Office Protocol - Version 3
Extended Service
Status of This
This memo suggests a simple method for workstations to
access mail from a discussion group server, as an extension to
earlier memo which dealt with dynamically accessing mail from
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
extensions described in this memo to the POP3 are OPTIONAL
Distribution of this memo is unlimited
Introduction and
It is assumed that the reader is familiar with RFC 1081
discusses the Post Office Protocol - Version 3 (POP3) [RFC1081].
This memo describes extensions to the POP3 which enhance the
it offers to clients. This additional service permits a client
to access discussion group mail, which is often kept in a
spool area, using the general POP3 facilities
The next section describes the evolution of discussion groups and
technologies currently used to implement them. To summarize
o An exploder is used to map from a single address
a list of addresses which subscribe to the list, and
any subsequent error reports associated with the delivery
each message. This has two primary advantages
- Subscribers need know only a single
- Responsible parties get the error reports and
the
Rose [Page 1]
RFC 1082 POP3 Extended Service November 1988
o Typically, each subscription address is not a person's
maildrop, but a system-wide maildrop, which can be
by more than one user. This has several advantages
- Only a single copy of each message need traverse
net for a given site (which may contain several
hosts). This conserves bandwidth and cycles
- Only a single copy of each message need reside on
subscribing host. This conserves disk space
- The private maildrop for each user is not
with discussion group mail
Despite this optimization of resources, further economy can
achieved at sites with more than one host. Typically, sites
more than one host either
1. Replicate discussion group mail on each host.
results in literally gigabytes of disk space committed
unnecessarily store redundant information
2. Keep discussion group mail on one host and give all users
login on that host (in addition to any other logins they
have). This is usually a gross inconvenience for users
work on other hosts, or a burden to users who are forced
work on that host
As discussed in [RFC1081], the problem of giving workstations
access to mail from a mailbox server has been explored in
detail (originally there was [RFC918], this prompted the author
write [RFC1081], independently of this [RFC918] was upgraded
[RFC937]). A natural solution to the problem outlined above is
keep discussion group mail on a mailbox server at each site
permit different hosts at that site to employ the POP3 to
discussion group mail. If implemented properly, this avoids
problems of both strategies outlined above
ASIDE: It might be noted that a good distributed
could also solve this problem. Sadly, "good
distributed filesystems, which do not
unacceptable response time for interactive use,
few and far between these days
Given this motivation, now let's consider discussion groups, both
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
experiences
Rose [Page 2]
RFC 1082 POP3 Extended Service November 1988
What's in a Discussion
Since mailers and user agents first crawled out of the
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
subscribers with a common interest. These subscribers post mail to
single address, known as a distribution address. From
distribution address, a copy of the message is sent to
subscriber. Each group has a moderator, which is the person
administrates the group. The moderator can usually be reached at
special address, known as a request address. Usually,
responsibilities of the moderator are quite simple, since the
system handles the distribution to subscribers automatically.
some cases, the interest group, instead of being distributed
to its subscribers, is put into a digest format by the moderator
then sent to the subscribers. Although this requires more work
the part of the moderator, such groups tend to be better organized
Unfortunately, there are a few problems with the scheme
above. First, if two users on the same host subscribe to the
interest group, two copies of the message get delivered. This
wasteful of both processor and disk resources
Second, some of these groups carry a lot of traffic.
subscription to an group does indicate interest on the part of
subscriber, it is usually not interesting to get 50 messages or
delivered to the user's private maildrop each day, interspersed
personal mail, that is likely to be of a much more important
timely nature
Third, if a subscriber on the distribution list for a group
"bad" somehow, the originator of the message and not the moderator
the group is notified. It is not uncommon for a large list to
10 or so bogus addresses present. This results in the
being flooded with "error messages" from mailers across the
stating that a given address on the list was bad. Needless to say
the originator usually could not care less if the bogus addresses
a copy of the message or not. The originator is merely interested
posting a message to the group at large. Furthermore, the
of the group does care if there are bogus addresses on the list,
ironically does not receive notification
There are various approaches which can be used to solve some or
of these problems. Usually these involve placing an exploder
at the distribution source of the discussion group, which expands
name of the group into the list of subscription addresses for
Rose [Page 3]
RFC 1082 POP3 Extended Service November 1988
group. In the process, the exploder will also change the
that receives error notifications to be the request address or
responsible party
A complementary approach, used in order to cut down on
utilization of all kinds, replaces all the subscribers at a
host (or group of hosts under a single administration) with a
address at that host. This address maps to a file on the host
usually in a spool area, which all users can access. (
implementations can also implement private discussion groups
way, in which a single copy of each message is kept, but
accessible to only a select number of users on the host.)
The two approaches can be combined to avoid all of the
described above
Finally, a third approach can be taken, which can be used to aid
agents processing mail for the discussion group: In order to
querying of the maildrop which contains the local host's copy of
discussion group, two other items are usually associated with
discussion group, on a local basis. These are the maxima and
last-date. Each time a message is received for the group on
local host, the maxima is increased by at least one. Furthermore
when a new maxima is generated, the current date is determined.
is called the last date. As the message is entered into the
maildrop, it is given the current maxima and last-date. This
the user agent to quickly determine if new messages are present
the maildrop
NOTE: The maxima may be characterized as a
increasing quanity. Although sucessive values of
maxima need not be consecutive, any maxima
is always greater than any previously assigned value
Definition of
To formalize these notions somewhat, consider the following 7
parameters which describe a given discussion group from
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
Syntax: TOKEN (ALPHA *[ ALPHA / DIGIT / "-" ])
(case-insensitive recognition
Example: unix-
ALIASES Meaning: alternates names for the group,
are locally meaningful; these
typically used to shorten user
Syntax: TOKEN (case-insensitive recognition
Example:
ADDRESS Meaning: the primary source of the
Syntax: 822
Example: Unix-Wizards@BRL.
REQUEST Meaning: the primary moderator of the
Syntax: 822
Example: Unix-Wizards-Request@BRL.
FLAGS Meaning: locally meaningful flags
with the discussion group; this
leaves interpretation of
parameter to each POP3
Syntax: octal
Example: 01
MAXIMA Meaning: the magic cookie associated with
last message locally received for
group; it is the property of the
cookie that it's value
decreases, and increases by at
one each time a message is
Syntax: decimal
Example: 1004
LASTDATE Meaning: the date that the last message
locally
Syntax: 822
Example: Thu, 19 Dec 85 10:26:48 -0800
Note that the last two values are locally determined for the
associated with the discussion group and with each message in
maildrop. Note however that the last message in the maildrop have
different MAXIMA and LASTDATE than the discussion group. This
occurs when the maildrop has been archived
Rose [Page 5]
RFC 1082 POP3 Extended Service November 1988
Finally, some local systems provide mechanisms for
archiving discussion group mail. In some cases, a two-level
scheme is used: current mail is kept in the standard maildrop
recent mail is kept in an archive maildrop, and older mail is
off-line. With this scheme, in addition to having a "standard
maildrop for each discussion group, an "archive" maildrop may also
available. This permits a user agent to examine the most
archive using the same mechanisms as those used on the current mail
The XTND
The following commands are valid only in the TRANSACTION state of
POP3. This implies that the POP3 server has already opened
user's maildrop (which may be empty). This maildrop is called
"default maildrop". The phrase "closes the current maildrop" has
meanings, depending on whether the current maildrop is the
maildrop or is a maildrop associated with a discussion group
In the former context, when the current maildrop is closed
messages marked as deleted are removed from the maildrop currently
use. The exclusive-access lock on the maildrop is then
along with any implementation-specific resources (e.g., file
descriptors).
In the latter context, a maildrop associated with a discussion
is considered to be read-only to the POP3 client. In this case,
phrase "closes the current maildrop" merely means that
implementation-specific resources are released. (Hence, the POP
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
"discussion group listing" which presents the name of the
group along with it's maxima. In order to simplify parsing all POP
servers are required to use a certain format for discussion
listings
NAME SP
This memo makes no requirement on what follows the maxima in
listing. Minimal implementations should just end that line of
response with a CRLF pair. More advanced implementations may
other information, as parsed from the message
NOTE: This memo STRONGLY discourages implementations
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
maildrop. The POP3 server then validates the argument as the name
a discussion group. If this is successful, it opens the
associated with the group, and returns a multi-line
containing the discussion group listing. If the discussion
named is not valid, or the associated archive maildrop is
readable by the user, then an error response is returned
If no argument was given, the POP3 server issues a multi-
response. After the initial +OK, for each discussion group known
the POP3 server responds with a line containing the listing for
discussion group. Note that only world-readable discussion
are included in the multi-line response
In order to aid user agents, this memo requires an extension to
scan listing when an "XTND BBOARDS" command has been given
Normally, a scan listing, as generated by the LIST, takes the form
MSGNO
where MSGNO is the number of the message being listed and SIZE is
size of the message in octets. When reading a maildrop accessed
"XTND BBOARDS", the scan listing takes the
MSGNO SIZE
where MAXIMA is the maxima that was assigned to the message when
was placed in the BBoard
Possible Responses
+OK
-ERR no such
Examples
C: XTND
S: +OK
S: system 10
S: mh-users 100
S: .
C: XTND BBOARDS
S: + OK
S: system 10
S: .
Rose [Page 7]
RFC 1082 POP3 Extended Service November 1988
XTND ARCHIVE
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
validates the argument as the name of a discussion group. If this
successful, it opens the archive maildrop associated with the group
and returns a multi-line response containing the discussion
listing. If the discussion group named is not valid, or
associated archive maildrop is not readable by the user, then
error response is returned
In addition, the scan listing generated by the LIST command
augmented (as described above).
Possible Responses
+OK
-ERR no such bboard Examples
C: XTND ARCHIVE
S: + OK
S: system 3
S: .
XTND X-BBOARDS
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
discussion group. If this is unsuccessful, then an
response is returned. Otherwise a multi-line response
returned. The first 14 lines of this response (after
initial +OK) are defined in this memo. Minimal
need not include other information (and may omit
information, outputing a bare CRLF pair). More
implementations may include other information
Line Information (refer to "Definition of Terms")
---- -----------
1
2 ALIASES, separated by
3 system-specific:
4 system-specific: archive
5 system-specific:
6 system-specific: maildrop
7 system-specific: encrypted
8 system-specific: local leaders, separated by
Rose [Page 8]
RFC 1082 POP3 Extended Service November 1988
9
10
11 system-specific: incoming
12 system-specific: outgoing
13 FLAGS SP
14
Most of this information is entirely too specific to the UCI
of the Rand MH Message Handling System [MRose85]. Nevertheless
lines 1, 2, 9, 10, 13, and 14 are of general interest, regardless
the implementation
Possible Responses
+OK
-ERR no such
Examples
C: XTND X-BBOARDS
S: + OK
S:
S: local
S: /usr/bboards/system.
S: /usr/bboards/archive/system.
S: /usr/bboards/.system.
S: /usr/bboards/.system.
S: *
S:
S: system@nrtc.northrop.
S: system-request@nrtc.northrop.
S
S: dist-system@nrtc-gremlin.northrop.
S: 01 10
S: Thu, 19 Dec 85 00:08:49 -0800
S: .
Policy
Depending on the particular entity administrating the POP3
host, two additional policies might be implemented
1. Private Discussion
In the general case, discussion groups are world-readable, any user
once logged in (via a terminal, terminal server, or POP3, etc.),
able to read the maildrop for each discussion group known to the POP
service host. Nevertheless, it is desirable, usually for
reasons, to implement private discussion groups as well
Support of this is consistent with the extensions outlined in
Rose [Page 9]
RFC 1082 POP3 Extended Service November 1988
memo. Once the AUTHORIZATION state has successfully concluded,
POP3 server grants the user access to exactly those discussion
the POP3 service host permits the authenticated user to access. As
"security" feature, discussion groups associated with
maildrops should not be listed in a positive response to the
BBOARDS command
2. Anonymous POP3
In order to minimize the authentication problem, a policy
"anonymous" access to the world-readable maildrops for
groups on the POP3 server may be implemented
Support of this is consistent with the extensions outlined in
memo. The POP3 server can be modified to accept a USER command for
well-known pseudonym (i.e., "anonymous") which is valid with any
command. As a "security" feature, it is advisable to limit this
of access to only hosts at the local site, or to hosts named in
access list
Experiences and
All of the facilities described in this memo and in [RFC1081]
been implemented in MH #6.1. Initial experiences have been, on
whole, very positive
After the first implementation, some performance tuning was required
This consisted primarily of caching the datastructures which
discussion groups in the POP3 server. A second
pertained to the client: the program most commonly used to
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)
the message are required (e.g., for a scan listing), then
these are retrieved. The resulting output is then cached,
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
POP3 server and client are connected via a high-speed local
network. In fact, the author uses this mechanism to access
private discussion groups over the Internet. In this case,
is still good. When a 9.6Kbps modem is inserted in the path
response went from good to almost tolerable (fortunately the
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
for discussion group mail as well
[RFC1081] Rose, M., "Post Office Protocol - Verison 3 (POP3)",
1081, TWG, November 1988.
[MRose85] Rose, M., and J. Romine, "The Rand MH Message
System: User's Manual", University of California, Irvine
November 1985.
[RFC822] Crocker, D., "Standard for the Format of ARPA-
Text Messages", RFC 822, University of Delaware,
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
The Wollongong
1129 San Antonio Rd
Palo Alto, California 94303
Phone: (415) 962-7100
Email: MRose@TWG.
Rose [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
