620 lines
24 KiB
Plaintext
620 lines
24 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|