As per Relevance of the word followed, we have this rfc below:
Network Working Group M.
Request for Comments: 1056
Obsoletes: RFC-993 June 1988
PCMAIL: A Distributed Mail System for Personal
Table of
1. Status of this Document 1
2. Introduction 2
3. Repository architecture 4
3.1. Management of user mail state 5
3.2. Repository-to-RFC-822 name translation 7
4. Communication between repository and client: DMSP 8
4.1. DMSP commands 8
4.2. DMSP responses 8
4.3. DMSP sessions 11
4.4. General operations 11
4.5. User operations 12
4.6. Client operations 13
4.7. Mailbox operations 14
4.8. Address operations 15
4.9. Subscription operations 15
4.10. Message operations 16
5. Client Architecture 18
5.1. Multiple clients 18
5.2. Synchronization 18
5.3. Batch operation versus interactive operation 20
5.4. Message summaries 20
6. Typical interactive-style client-repository interaction 21
7. A current Pcmail implementation 25
7.1. IBM PC client code 25
7.2. UNIX client code 26
7.3. Repository code 26
8. Conclusions 26
I. DMSP Protocol Specification 28
II. Operations by name 37
III. Responses by number 38
1. Status of this
This RFC is a discussion of the Pcmail workstation based
mail system. It is identical to the discussion in RFC-993, save
a new, much simpler mail transport protocol is described. The
transport protocol is the result of continued research into ease
protocol implementation and use issues. Distribution of this memo
unlimited
Lambert [Page 1]
RFC 1056 PCMAIL June 1988
2.
Pcmail is a distributed mail system providing mail service to
arbitrary number of users, each of whom owns one or
workstations. Pcmail's motivation is to provide very flexible
service to a wide variety of different workstations, ranging in
from small, resource-limited machines like IBM PCs to resource-
(where "resources" are primarily processor speed and disk space
machines like Suns or Microvaxes. It attempts to provide
service to resource-limited workstations while still providing
service to resource-rich machines. It is intended to work well
machines only infrequently connected to a network as well as
permanently connected to a network. It is also designed to
diskless workstations full mail service
The system is divided into two halves. The first consists of
single entity called the "repository". The repository is a
center for incoming mail. Mail for a Pcmail user can
externally from the Internet or internally from other
users. The repository also maintains a stable copy of each user'
mail state (this will hereafter be referred to as the user's "
mail state"). The repository is therefore typically a computer
a large amount of disk storage
The second half of Pcmail consists of one or more "clients".
Pcmail user may have an arbitrary number of clients,
single-user workstations. The clients provide a user with a
means of accessing the user's global mail state over a network.
order to make the interaction between the repository and a user'
clients more efficient, each client maintains a local copy of
user's global mail state, called the "local mail state". It
assumed that clients, possibly being small personal computers,
not always have access to a network (and therefore to the global
state in the repository). This means that the local and global
states may not be identical all the time, making
between local and global mail states necessary
Clients communicate with the repository via the Distributed
System Protocol (DMSP); the specification for this protocol
in appendix A. The repository is therefore a DMSP server in
to a mail end-site and storage facility. DMSP provides a
set of mail manipulation operations ("send a message", "delete
message", "print a message", etc.). DMSP also provides
operations to allow easy synchronization between a user's global
state and his clients' local mail states. Particular attention
been paid to the way in which DMSP operations act on a user's
state. All DMSP operations are failure-atomic (that is, they
guaranteed either to succeed completely, or leave the user's
Lambert [Page 2]
RFC 1056 PCMAIL June 1988
state unchanged ). A client can be abruptly disconnected from
repository without leaving inconsistent or damaged mail states
Pcmail's design has been directed by the characteristics of
available workstations. Some workstations are fairly portable,
can be packed up and moved in the back seat of an automobile. A
are truly portable--about the size of a briefcase--and battery
powered. Some workstations have constant access to a high-
local-area network; pcmail should allow for "on-line" mail
for these machines while at the same time providing "batch"
delivery for other workstations that are not always connected to
network. Portable and semi-portable workstations tend to
resource-poor. A typical IBM PC has a small amount (typically
than one megabyte) of main memory and little in the way of
storage (floppy-disk drives that can access perhaps 360 kilobytes
data). Pcmail must be able to provide machines like this
adequate mail service without hampering its performance on
resource-rich workstations. Finally, all workstations have
common characteristics that Pcmail should take advantage of.
instance, workstations are fairly inexpensive compared to the
time-shared systems that most people use for mail service.
means that people may own more than one workstation, perhaps
a Microvax in an office and an IBM PC at home
Pcmail's design reflects the differing characteristics of the
workstations. Since one person can own several workstations,
allows users multiple access points to their mail state. Each
user can have several client workstations, each of which can
the user's mail by communicating with the repository over a network
The clients all maintain local copies of the user's global
state, and synchronize the local and global states using DMSP
It is also possible that some workstations will only infrequently
connected to a network (and thus be able to communicate with
repository). The Pcmail design therefore allows two modes
communication between repository and client. "Interactive mode"
used when the client is always connected to the network. Any
to the client's local mail state are immediately also made to
repository's global mail state, and any incoming mail is
transmitted from repository to client. "Batch mode" is used
clients that have infrequent access to the repository.
manipulate the client's local mail state, queueing the
locally. When the client is next connected to the repository,
changes are executed, and the client's local mail state
synchronized with the repository's global mail state
Finally, the Pcmail design minimizes the effect of using a resource
poor workstation as a client. Mail messages are split into
Lambert [Page 3]
RFC 1056 PCMAIL June 1988
parts: a "descriptor" and a "body". The descriptor is a
message summary whose length (typically about 100 bytes)
independent of the actual message length. The body is the
message text, including an RFC-822 standard message header.
the client may not have enough storage to hold a complete set
messages, it can usually hold a complete set of descriptors,
providing the user with at least a summary of his mail state.
clients with extremely limited resources, Pcmail allows the
of partial sets of descriptors. Although this means the user
not have a complete local mail state, he can at least look
summaries of some messages. In the cases where the client
immediately store message bodies, it can always pull them over
the repository as storage becomes available
The remainder of this document is broken up into sections
the following
- The repository
- DMSP, its operations, and motivation for its
- The client
- A typical DMSP session between the repository and
- The current Pcmail
- Appendices describing the DMSP protocol in
3. Repository
A typical machine running repository code has a relatively
processor and a large amount of disk storage. It must also be
permanent network site, for two reasons. First, clients
with the repository over a network, and rely on the repository'
being available at any time. Second, people sending mail
repository users rely on the repository's being available to
mail at any time
The repository must perform several tasks. First, and
importantly, the repository must efficiently manage a
large number of users and their mail states. Mail must be
stored in a manner that makes it easy for multiple clients to
the global mail state and synchronize their local mail states
the global state. Since a large category of electronic mail
represented by bulletin boards (bboards), the repository
efficiently manage bboard mail, using a minimum of storage to
Lambert [Page 4]
RFC 1056 PCMAIL June 1988
bboard messages in a manner that still allows any user subscribing
the bboard to read the mail. Second, the repository must be able
communicate efficiently with its clients. The protocol used
communicate between repository and client must be reliable and
provide operations that (1) allow typical mail manipulation, and (2)
support Pcmail's distributed nature by allowing
synchronization between local and global mail states. Third,
repository must be able to process mail from sources outside
repository's own user community (a primary outside source is
Internet). Internet mail will arrive with a NIC RFC-822
message header; the recipient names in the message must be
translated from the RFC-822 namespace into the repository'
namespace
3.1. Management of user mail
Pcmail divides the world into a community of users. Each user
associated with a user object. A user object consists of a
name, a password (which the user's clients use to
themselves to the repository before manipulating a global
state), a list of "client objects" describing those clients
to the user, a list of "subscription objects", and a list of "
objects".
A client object consists of a unique name and a status. A user
one client object for every client he owns; a client
communicate with the repository unless it has a corresponding
object in a user's client list. Client objects therefore serve as
means of identifying valid clients to the repository. Client
also allow the repository to manage local and global mail
synchronization; the repository associates with every client
"update list" of message state changes which have occurred since
client's last synchronization
A client's status is either "active" or "inactive". The
defines inactive clients as those clients which have not connected
the repository within a set time period (one week in the
repository implementation). When a previously-inactive client
connect to the repository, the repository notifies the client that
has been inactive for some time and should "reset" itself.
a client has the effect of placing every message in every
onto the client's update list. This allows the client to get a
global mail state from the repository when it next synchronizes (
synchronization discussion following). The reset is performed on
assumption that enough global state changes occur in a week that
client would spend too much time performing an ordinary local state
global state synchronization
Lambert [Page 5]
RFC 1056 PCMAIL June 1988
Messages are stored in mailboxes. Users can have any number
mailboxes, which serve both to store and to categorize messages.
mailbox object both names a mailbox and describes its contents
Mailboxes are identified by a unique name; their contents
described by three numeric values. The first is the total number
messages in the mailbox, the second is the total number of
messages (messages that have never been seen by the user via
client) in the mailbox, and the third is the mailbox's next
message unique identifier (UID). The above information is stored
the mailbox object to allow clients to get a summary of a mailbox'
contents without having to read all the messages within the mailbox
Some mailboxes are special, in that other users may read the
stored in them. These mailboxes are called "bulletin
mailboxes" or "bboard mailboxes". The repository uses
mailboxes to store bboard mail. Bboard mailboxes differ
ordinary mailboxes in the following ways
- Their names are unique across the entire repository
for instance, only one bboard mailbox named "sf-lovers
may exist in the entire repository community.
does not preclude other users from having an
mailbox named "sf-lovers".
- Subscribers to the bboard are granted read-only
to the messages in the bboard mailbox. The
mailbox's owner (typically the system manager)
read/update/delete access to the mailbox
A bboard subscriber keeps track of the messages he has looked at
a subscription object. The subscription object contains the name
the bboard, its owner (the user who owns the bboard mailbox where
the messages are stored), and the UID of the first message not
seen by the subscriber
Users gain read-only access to a bboard by creating a subscription
it; they lose that access when they delete that subscription. A
of all bboard mailboxes available for subscription can be
to the user on demand
Associated with each mailbox are any number of message objects.
message is broken into two parts--a "descriptor", which contains
summary of useful information about the message, and a "body",
is the message text itself, including its NIC RFC-822 message header
Each message is assigned a monotonically increasing UID based on
owning mailbox's next available UID. Each mailbox has its own set
UIDs which, together with the mailbox name and user name,
identify the message within the repository. A descriptor holds
Lambert [Page 6]
RFC 1056 PCMAIL June 1988
following information: the message UID, the message size in
and lines, four "useful" message header fields (the "date:", "to:",
"from:", and "subject:" fields), and sixteen flags. These flags
given identifying numbers 0 through 15. Eight of these flags
well-known definitions and are reserved for the repository's use
The eight repository-defined flags mark
- (#0) whether the message has been
- (#1) whether it has been
- (#2) whether it has been forwarded to the
- (#3) whether it has been forwarded by the
- (#4) whether it has been filed (written to a text
outside the repository
- (#5) whether it has been printed (locally or remotely
- (#6) whether it has been replied
- (#7) whether it has been copied to another
The remaining eight flags are availble for user use.
serve as an efficient means for clients to get message
without having to waste time retrieving the entire message from
repository
3.2. Repository-to-RFC-822 name
"Address objects" provide the repository with a means for
the RFC-822-style mail addresses in Internet messages into
names. The repository provides its own namespace for
identification. Any message is uniquely identified by the
(user-name, mailbox-name, message-UID). Any mailbox is
identified by the pair (user-name, mailbox-name). In order
translate between RFC-822-style mail addresses and repository names
the repository maintains a list of address objects. Each
object is an association between an RFC-822-style address and
(user-name, mailbox-name) pair. When mail arrives from the Internet
the repository can use the address object list to translate
recipients into (user-name, mailbox-name) pairs and route the
correctly
Lambert [Page 7]
RFC 1056 PCMAIL June 1988
4. Communication between repository and client:
The Distributed Mail System Protocol (DMSP) defines and
the objects mentioned in the previous section. It has been
to work with Pcmail's singlerepository/multiple-client model of
world. In addition to providing typical mail manipulation functions
DMSP provides functions that allow easy synchronization of global
local mail states
DMSP has been completely re-specified in this version of Pcmail
Formerly, DMSP was implemented on top of the USP remote-procedure
call protocol. Since this protocol is not fully
specified (let alone officially specified) anywhere,
of USP is difficult for sites wishing to implement Pcmail
different systems. We therefore have decided to completely
DMSP. It is now a very simple request/response protocol similar
SMTP or NNTP, running directly on a reliable bidirectional byte
stream such as TCP. The TCP contact port for DMSP has
designated 158. Requests and responses consist of ASCII characters
on octet-based transmission streams, each character is
rightjustified in an octet with the high-order bit cleared to zero
4.1. DMSP
DMSP operations consist of an operation name, followed by zero
more tab or space characters, followed by zero or more arguments
each of which is separated from the operation name and
arguments by one or more space or tab characters. All
requests, as well as all responses, must be terminated with
carriage-return plus line-feed (CR-LF) pair. All operation names
arguments must be taken from the set of alphanumeric characters
the characters dash ("-"), underscore ("_"), and period (".").
DMSP operation names are case-insensitive; they may be transmitted
any combination of upper and lower case. DMSP arguments are case
insensitive but case-preserving; in other words a mailbox
"MarkL" may be referred to by an operation argument "markl", but
always be stored, and transmitted in a repository response,
"MarkL"; furthermore, any attempt to create a new mailbox "MaRkL
will not be permitted
Each operation argument may contain no more than 64 characters.
single request or response line may contain more than 512 characters
including all white space and the terminating CR-LF
4.2. DMSP
A DMSP operation always results in a response, which may be
Lambert [Page 8]
RFC 1056 PCMAIL June 1988
in turn by a list, consisting of zero or more lines of CR-LF
terminated text terminated by a single period (".") plus a CR-LF.
response is always prefaced by a three-digit reply code;
text following the response code can be in any format. The
code is sufficient to determine whether the operation succeeded
failed, or whether more text is forthcoming following the
line. Any text following the response code is for information only
and need not follow any particular format
The first digit indicates whether the operation succeeded or failed
and if it succeeded whether or not more text should be presented
the repository. Definitions of the first digit are similar to
of NNTP
1XX Informative
2XX Operation completed
3XX Operation completed successfully,
remainder of text and terminate with a
period plus CR-LF pair
4XX Operation was performed and failed for
reason
5XX Operation could not be performed because of
protocol syntax error of some sort
The second digit indicates the type of object referred to by
response
X0X
X1X User
X2X Client
X3X Mailbox
Lambert [Page 9]
RFC 1056 PCMAIL June 1988
X4X Subscription
X5X Message
X6X Address
In an error response, the final digit can describe the type of
that occurred. Otherwise, it simply gives a response a
number. Numbers 0 through 3 are significant in 4XX-class (error
responses only. Numbers 0-9 in all other responses serve only
differentiate responses dealing with the same type of object
different circumstances
4X0 Operation failed because object
4X1 Operation failed because object does not
4X2 Operation failed because of an internal
4X3 Operation failed because of an argument
Each operation generates one of a set of responses, detailed in
protocol specification appendix
List termination is determined solely by a well-known
sequence (CR-LF, period, CR-LF). Since application data could
accidentally contain this termination sequence, the
protocol module must modify application data so it contains
termination sequences. The receiving module must similarly undo
modification before presenting the data to the application at
receiving end
The transmitting module modifies application data as follows: If
line of application data begins with a period, that period
duplicated. Since the termination sequence is a single period
accidental termination has now been prevented
The receiving protocol checks incoming all incoming data lines for
leading period. A single period is a list terminator; a
followed by other text is removed before being presented to
Lambert [Page 10]
RFC 1056 PCMAIL June 1988
receiving application
4.3. DMSP
A DMSP session proceeds as follows: a client begins the session
the repository by opening a connection to the repository's machine
The client then authenticates both itself and its user to
repository with a "login" operation. If the authentication
successful, the user performs an arbitrary number of DMSP
before ending the session with a "logout" operation, at which
the connection is closed by the repository
Because DMSP can manipulate a pair of mail states (local and global
at once, it is extremely important that all DMSP operations
failure-atomic. Failure of any DMSP operation must leave both
in a consistent, known state. For this reason, a DMSP operation
defined to have failed unless an explicit acknowledgement is
by the operation initiator. This acknowledgement consists of
response code possibly followed by information, as described above
Following is a general discussion of all the DMSP operations.
operations are broken down by type: general operations,
operations, client operations, mailbox operations,
operations, subscription operations, and message operations
Detailed operation specifications appear at the end of this document
4.4. General
The first group of DMSP operations perform general functions
operate on no one particular class of object. DMSP has three
operations which provide the following services
In order to prevent protocol version skew between clients and
repository, DMSP provides a "send-version" operation. The
supplies its DMSP version number as an argument; the
succeeds if the supplied version number matches the repository's
version number. It fails if the two version numbers do not match
The version number is a natural number like "100", "101", "200".
"send-version" operation should be the first that a client sends
the repository, since no other operation may work correctly if
client and repository are using different versions of DMSP
Users can send mail to other users via the "send-message" operation
The message must have an Internet-style header as defined by
RFC-822. The repository takes the message and distributes it to
mailboxes specified by the message header's destination fields.
one or more of the mailboxes exists outside the repository's
community, the repository is responsible for handing the message to
Lambert [Page 11]
RFC 1056 PCMAIL June 1988
local SMTP server. The message envelope is generated by
repository from the message contents since it may be difficult
some clients to perform envelope-generation functions such as
verification and syntax checking
A success acknowledgement is sent from the repository only if (1)
entire message was successfully transmitted from client
repository, and (2) the message header was properly formatted.
the repository has successfully received the message from the client
any subsequent errors in queueing or delivery must be noted
return mail to the user
The last general operation is the "help" operation. The
responds to "help" by printing an acknowledgement followed by a
of supported commands, terminated with a period plus CR-LF.
information is intended for display and can be in any format as
as the individual lines of text returned by the repository are CR
LF-terminated
4.5. User
The next series of DMSP operations manipulates user objects.
most common of these operations are "login" and "logout". A
must perform a login operation before being able to access a user'
mail state. A DMSP login operation takes five arguments: (1)
user's name, (2) the user's password, (3) the name of the
performing the login, (4) a flag set to 1 if the repository
create a client object for the client if one does not exist (0 else),
and (5) a flag set to 1 if the client wishes to operate in "
mode" and 0 if the client wishes to operate in "interactive" mode
The last flag value allows the repository to tune internal
for either mode of operation
The repository can make one of three responses. First, it can make
success response, indicating successful authentication. Second,
can make one of several failure responses, indicating
authentication. Finally, it can make a special response
that authentication was successful, but that the client has not
used in over a week. This last response serves as a hint that
client should consider erasing its local mail state and pulling
a complete version of the repository's mail state. This is done
the assumption that so many mail state changes have been made in
week that it would be inefficient to perform a
synchronization
When a client has completed a session with the repository,
performs a logout operation. This allows the repository to
any necessary cleanup before closing the network connection
Lambert [Page 12]
RFC 1056 PCMAIL June 1988
A user can change his password via the "set-password" operation.
operation works much the same as the UNIX change-password operation
taking as arguments the user's current password and a desired
password. If the current password given matches the user's
password, the user's current password is changed to the new
given. Because encryption can be difficult to perform on
resource-poor clients, passwords are transmitted in clear text
Clearly this is not an acceptable long-term solution,
alternatives are welcomed
4.6. Client
DMSP provides four operations to manipulate client objects.
first, "list-clients", tells the repository to send the user's
list to the requesting client. The list is a series of lines,
per client, containing the client's name, followed by whitespace
followed by a status string. The status is either "inactive"
"active". As with all text responses, the list is terminated with
period plus CR-LF
The "create-client" operation allows a user to add a client object
his list of client objects. Although the login operation
this functionality via the "create-this- client?" flag, the create
client operation is a useful means of creating a number of new
objects while logged into the repository via an existing client.
create-client operation requires as an argument the name of
client to create
The "delete-client" operation removes an existing client object
a user's client list. The client being removed cannot be in use
anyone at the time. Delete-client also requires as an argument
name of the client to delete
The last client operation, "reset-client", causes the repository
place all of the messages in all mailboxes onto the named client'
update list. When a client next synchronizes with the repository,
will end up receiving a list of all descriptors when it requests
list of changed message descriptors for a particular mailbox.
is useful for two reasons. First, a client's local mail state
easily become lost or damaged, especially if it is stored on a
disk. Second, if a client has been marked as inactive by
repository, the reset-client operation provides a fast way
resynchronizing with the repository, assuming that so
differences exist between the local and global mail states that
normal synchronization would take far too much time
Lambert [Page 13]
RFC 1056 PCMAIL June 1988
4.7. Mailbox
DMSP supports seven operations that manipulate mailbox objects
First, "list-mailboxes" has the repository send to the
client information on each mailbox. The repository transmits
line of information per mailbox, terminating the list with a
plus CR-LF. Each line contains, in order and separated
whitespace, the mailbox name, "next available UID", total
count, and unseen message count. This operation is useful
synchronizing local and global mail states, since it allows a
to compare the user's global mailbox list with a client's
mailbox list. The list of mailboxes also provides a quick summary
each mailbox's contents without having the contents present
The "create-mailbox" has the repository create a new mailbox
attach it to the user's list of mailboxes. It takes as an
the name of the mailbox to create
"Delete-mailbox" removes a mailbox from the user's list of mailboxes
All messages within the mailbox are also deleted and
removed from the system. Any address objects binding the
name to RFC-822-style mailbox addresses are also removed from
system. Delete-mailbox takes as an argument the name of the
to delete
"Create-bboard-mailbox" allows a user to create a bboard mailbox
The name given as an argument must be unique across the
repository user community. Once the bboard mailbox has been created
other users may subscribe to it, using subscription objects to
track of which messages they have read on which bboard mailboxes
"Delete-bboard-mailbox" allows a bboard's owner to delete a
mailbox. Subscribers who attempt to read from a bboard mailbox
it has been deleted are told that the bboard no longer exists
Again, the operation's argument is the name of the bboard mailbox
delete
"Reset-mailbox" causes the repository to place all of the messages
a named mailbox onto the current client's update list. When
client next requests a list of changed message descriptors for
mailbox, it will receive a list of all message descriptors in
mailbox. This operation is merely a more specific version of
reset-client operation (which allows the client to pull over
complete copy of the user's global mail state). Its primary use
for mailboxes whose contents have accidentally been
locally
Finally, DMSP has an "expunge-mailbox" operation. Any message can
Lambert [Page 14]
RFC 1056 PCMAIL June 1988
deleted and "undeleted" at will, since this simply changes the
of a flag attached to the message. Deletions are made permanent
performing an expunge-mailbox operation. The expunge
causes the repository to look through a named mailbox, removing
the system any messages marked "deleted". Expunge-mailbox takes
an argument the name of the mailbox to expunge
4.8. Address
DMSP provides three operations that allow users to manipulate
objects. First, the "list-address" operation returns a list
address objects associated with a particular mailbox. Each
is transmitted on a separate line terminated by a CR-LF; the list
terminated with a period plus CR-LF
The "create-address" operation adds a new address object
associates a (user-name, mailbox-name) pair with a given RFC-822-
style mailbox address. It takes as arguments the mailbox name
the address name
Finally, the "delete-address" operation destroys the address
binding the given RFC-822-style mail address and the given (user
name, mailbox-name) pair. Arguments are the address to delete
the mailbox it belongs to
4.9. Subscription
DMSP provides five subscription operations. The first, "list
subscriptions", gives the user a list of the bboards he is
subscribing to. The list consists of one line of information
subscription. Each entry contains the following information,
order
- The bulletin board's
- The UID of the first message the subscriber has not
- The number of messages the subscriber has not yet
- The highest message UID in the bulletin
"List-available-subscriptions" gives the user a list of all
he can subscribe to. The list consists of bboard names, one
line, terminated by a period plus CR-LF. "Createsubscription" adds
subscription to the user's list of subscriptions; it takes as
argument the name of the bboard to subscribe to. "Delete
subscription" removes a subscription from the list, and takes as
Lambert [Page 15]
RFC 1056 PCMAIL June 1988
argument the name of the subscription to remove. Note that this
not delete the associated bboard mailbox (obviously only the bboard'
owner can do that). It merely removes the user from the list of
bboard's subscribers. Finally DMSP allows the user to tell
repository which messages in a bboard he has seen.
subscription object contains the UID of the first message the
has not yet seen; the "reset-subscription" operation updates
number, insuring that the user sees a given bboard message only once
Reset-subscription takes as arguments the name of the
and the new UID value
4.10. Message
The most commonly-manipulated Pcmail objects are messages;
therefore provides special message operations to allow
synchronization, as well as a set of operations to perform
message-manipulation functions
A user may request a series of descriptors with the "fetch
descriptors" operation. The series is identified by a pair
message UIDs, representing the lower and upper bounds of the list
Since UIDs are defined to be monotonically increasing numbers, a
of UIDs is sufficient to completely identify the series
descriptors. If the lower bound UID does not exist, the
starts the series with the first message with UID greater than
lower bound. Similarly, if the upper bound does not exist,
repository ends the series with the last message with UID less
the upper bound. If certain UIDs within the series no longer exist
the repository obviously does not send them. The repository
the descriptors in a list with the following format
If a descriptor has been expunged, the repository transmits
consecutive lines of information: the word "expunged" on one line
followed by the message UID on the next line. "Expunged
notifications are only transmitted in response to a "fetch-changed
descriptors" command; they are an indication to the client
someone else has expunged the mailbox and that the client
remove the local copy of the expunged message
If a descriptor has not been expunged, it is presented as
consecutive lines of information: the word "descriptor" on the
line, followed by a second line containing the message UID,
states (see examples following), message length in bytes, and
length in lines, followed by four lines containing in order
message "from:" field, "to:" field, "date:" field, and "subject:"
field. The entire list of descriptors is terminated by a period
CR-LF; individual descriptors are not specially terminated since
first line ("expunged" or "descriptor") of a list entry
Lambert [Page 16]
RFC 1056 PCMAIL June 1988
the exact length of the entry (two lines or six lines).
The "fetch-changed-descriptors" operation is intended for use
state synchronization. Whenever a descriptor changes state (one
its flags is cleared, for example), the repository notes
clients which have not yet recorded the change locally. Fetch
changed-descriptors has the repository send to the client a
of the first N descriptors which have changed since the client's
synchronization, where N is a number sent by the client. The
sent begins with the descriptor with lowest UID. Note that the
of descriptors is only guaranteed to be monotonically increasing
a given call to "fetch-changed-descriptors"; messages with lower
may be changed by other clients in between calls to "fetch
changeddescriptors". "Fetch-changed-descriptors" takes
arguments: the name of the mailbox to search, and the maximum
of descriptors for the repository to return
Once the changed descriptors have been looked at, a user will want
inform the repository that the current client has recorded the
locally. The "reset-descriptors" command causes the repository
mark as "recorded by current client" a given series of descriptors
The series is identified by a low UID and a high UID. UIDs
the series that no longer exist are ignored. Arguments are:
name, low UID in range, and high UID in range
Whole messages are transmitted from repository to user with
"fetch-message" operation. The separation of "fetchdescriptors"
"fetch-message" operations allows clients with small amounts of
storage to obtain a small message summary (via "fetch-descriptors"
"fetch-changed-descriptors") without having to pull over the
message. Arguments are mailbox name, followed by message UID
Frequently, a message may be too large for some clients to
locally. Users can still look at the message contents via
"print-message" operation. This operation has the repository send
copy of the message to a named printer. The printer name need
have meaning to the particular repository implementation;
transmits the name only as a means of identification. Arguments are
mailbox name, followed by message UID, followed by
identification
Copying of one message into another mailbox is accomplished via
"copy-message" operation. A descriptor list of length one
containing a descriptor for the copied message, is returned if
copy operation is successful. This descriptor is required
the copied message acquires a UID different from the
message. The client cannot be expected to know which UID has
assigned the copy, hence the repository's sending a
Lambert [Page 17]
RFC 1056 PCMAIL June 1988
containing the UID. Arguments to copy-message are: source
name, target mailbox name, and source message UID
Each message has associated with it sixteen flags, as
earlier. These flags can be set and cleared using the "set-message
flag" operation. The first eight flags have special meaning to
repository as described above; the remaining eight are for user use
Set-message-flag takes four arguments: mailbox name, message UID
flag number (0 through 15), and desired flag state (0 or 1).
5. Client
Clients can be any of a number of different workstations; Pcmail'
architecture must therefore take into account the range
characteristics of these workstations. First, most workstations
much more affordable than the large computers currently used for
service. It is therefore possible that a user may well have
than one. Second, some workstations are portable and they are
expected to be constantly tied into a network. Finally, many of
smaller workstations resource-poor, so they are not expected to
able to store a significant amount of state information locally.
following subsections describe the particular parts of Pcmail'
client architecture that address these different characteristics
5.1. Multiple
The fact that Pcmail users may own more than one workstation
the rationale for the multiple client model that Pcmail uses.
Pcmail user may have one client at home, another at an office,
maybe even a third portable client. Each client maintains a
copy of the user's mail state, hence Pcmail's distributed nature
The notion of separate clients allows Pcmail users to access
state from several different locations. Pcmail places
restrictions on a user's ability to communicate with the
from several clients at the same time. Instead, the decision
allow several clients concurrent access to a user's mail state
made by the repository implementation
5.2.
Some workstations tend to be small and fairly portable;
likelihood of their always being connected to a network is
small. This is another reason for each client's maintaining a
copy of a user's mail state. The user can then manipulate the
mail state while not connected to the network (and the repository).
This immediately brings up the problem of synchronization
local and global mail states. The repository is continually in
position to receive global mail state updates, either in the form
Lambert [Page 18]
RFC 1056 PCMAIL June 1988
incoming mail, or in the form of changes from other clients.
client that is not always connected to the net cannot
receive the global changes. In addition, the client's user can
his own changes on the local mail state
Pcmail's architecture allows fast synchronization between
local mail states and the repository's global mail state.
client is identified in the repository by a client object attached
the user. This object forms the basis for synchronization
local and global mail states. Some of the less common state
include the adding and deleting of user mailboxes and the adding
deleting of address objects. Synchronization of these changes
performed via DMSP list operations, which allow clients to
their local versions of mailbox and address object lists with
repository's global version and make any appropriate changes.
majority of possible changes to a user's mail state are in the
of changed descriptors. Since most users will have a large number
messages, and message states will change relatively often,
attention needs to be paid to message synchronization
An existing descriptor can be changed in one of three ways: first
one of its sixteen flag values can be changed (this encompasses
user's reading an unseen message, deleting a message, printing
message, etc). Second, a descriptor can be created, either by
delivery of a new message or by the copying of a message from
mailbox to another. Finally, a descriptor can be destroyed, via
"expunge-mailbox" operation
In the above cases, synchronization is required between
repository and every client that has not previously noted the change
To keep track of which clients have noticed a global mail
change and changed their local states accordingly, each mailbox
associated with it a list of active clients. Each client has
(potentially empty) "update list" of messages which have
since that client last synchronized
When a client connects to the repository, it executes a DMSP "fetch
changed-descriptors" operation. This causes the repository to
a list of all descriptors on that client's update list. When
client receives the changed descriptors, it may do one of two things
if the descriptor is marked "expunged", it can remove
corresponding message from the local mailbox. If the descriptor
not expunged, the client can store the descriptor, thus updating
local mail state. After a changed descriptor has been recorded,
client uses the DMSP "reset-descriptors" operation to
descriptors from its update list. Those descriptors will now not
sent to the client unless (1) it is explicitly requested via
"fetch-descriptors" operation, or (2) it changes again
Lambert [Page 19]
RFC 1056 PCMAIL June 1988
In this manner, a client can run through its user's mailboxes
getting all changes, incorporating them into the local mail state
and marking the changes as recorded
5.3. Batch operation versus interactive
Because of the portable nature of some workstations, they may
always be connected to a network (and able to communicate with
repository). Since each client maintains a local mail state,
users can manipulate the local state while not connected to
repository. This is known as "batch" operation, since all
are recorded by the client and made to the repository's global
in a batch, when the client next connects to the repository
Interactive operation occurs when a client is always connected to
repository. In interactive mode, changes made to the local
state are also immediately made to the global state via
operations
In batch mode, interaction between client and repository takes
following form: the client connects to the repository and sends
all the changes made by the user to the local mail state.
repository changes its global mail state accordingly. When
changes have been processed, the client begins synchronization;
incorporates newly-arrived mail, as well as mail state changes
other clients, into the local state
In interactive mode, since local changes are immediately
to the repository, the first part of batch-type operation
eliminated. The synchronization process also changes; although
synchronization is required when the client first opens a
to the repository, subsequent synchronizations can be
either at the user's request or automatically every so often by
client
5.4. Message
Smaller workstations may have little in the way of disk storage
Clients running on these workstations may never have enough room
a complete local copy of a user's global mail state. This means
Pcmail's client architecture must allow user's to obtain a
picture of their mail state without having all their
present
Descriptors provide message information without taking up
amounts of storage. Each descriptor contains a summary
information on a message. This information includes the message UID
its length in bytes and lines, its status (contained in the
system-defined and eight user-defined flags), and portions of
Lambert [Page 20]
RFC 1056 PCMAIL June 1988
RFC-822 header (the "from:", "to:", "date:" and "subject:" fields).
All of this information can be encoded in a small (around 100 bytes
data structure whose length is independent of the size of the
it describes
Most clients should be able to store a complete list of
descriptors with little problem. This allows a user to get
complete picture of his mail state without having all his
present locally. If a client has extremely limited amounts of
storage, it is also possible to get a subset of the descriptors
the repository. Short messages can reside on the client, along
the descriptors, and long messages can either be printed via the
print-message operation, or specially pulled over via the fetch
message operation
6. Typical interactive-style client-repository
The following example describes a typical communication
between the repository and a client mail reader. The client is
of three belonging to user "Fred". Its name is "office-client",
since Fred has used the client within the last week, it is marked
"active". Fred has two mailboxes: "fred" is where all of
current mail is stored; "archive" is where messages of
importance are kept. The example will run through a
synchronization operation. Typically, the synchronization will
performed by a mail reader as part of a "get new mail" operation
First Fred's mail reader connects to the repository and receives
following banner
200 Pcmail repository version 3.0.0
In order to access his global mail state, the mail reader
authenticate Fred to the repository; this is done via the DMSP
operation
login fred fred-password office-client 0 0
This tells the repository that Fred is logging in via "office
client", and that "office-client" is identified by an existing
object in Fred's mail state. The first argument to the
operation is Fred's repository user name. The second argument
Fred's password. The third argument is the name of the
communicating with the repository. The fourth argument tells
repository not to create "office-client" even if it cannot find
client object. The final argument tells the repository that Fred'
client is not operating in batch mode but rather in interactive mode
Lambert [Page 21]
RFC 1056 PCMAIL June 1988
Fred's authentication checks out, so the repository logs him in
200 command
Now that Fred is logged in, the mail reader performs an
synchronization. This process starts with the mail reader's
for an up-to-date list of mailboxes
list-
The repository replies with
230 mailbox list follows
fred 2313 10 1
archive 101 100 0
.
This tells the mail reader that there are two mailboxes, "fred"
"archive". "Fred" has 10 messages, one of which is unseen. The
incoming message will be assigned a UID of 2313. "Archive", on
other hand, has 100 messages, none of which are unseen. The
message sent to "archive" will be assigned the UID 101. There are
new mailboxes in the list (if there were, the mail reader
create them. On the other hand, if some mailboxes in the
reader's local list were not in the repository's list, the
would assume them deleted by another client and delete them
as well).
To synchronize, the mail reader need only look at each mailbox'
contents to see if (1) any new mail has arrived, or (2) if
changed any messages on one of his other two clients subsequent
"office-client"'s last connection to the repository
The mail reader asks for any changed descriptors via the "fetch
changed-descriptors" operation. It requests at most ten
descriptors since storage is very limited on Fred's workstation
fetch-changed-descriptors fred 10
The repository responds with
250 descriptor list follows
Lambert [Page 22]
RFC 1056 PCMAIL June 1988
2101
2104
2107 1100011100000010 1400 30
foo@bar.edu (Foo Jones
fred@PTT.LCS.MIT.
Wed, 9 Dec 87 10:43:52
A typical subject
2312 0000000000000000 12232 320
joe@athena.mit.
fred@PTT.LCS.MIT.
Thu, 17 Dec 87 18:24:09
Another typical subject
.
If a descriptor changed because it was expunged, it is transmitted
two lines: the word "expunged" on one line, followed by the
UID on the next line. If one of its flags changed state, or it is
new message, it is transmitted as six lines: the word "descriptor"
one line, followed by a line containing the message UID, flags,
length in bytes and lines, followed by the to, from, date,
subject fields, each on one line. The flags are transmitted as
single string of ones and zeroes, a one if the flag is on and a
if the flag is off. All 16 flags are always transmitted.
zero's state is the first character in the flag string;
fifteen's is the last character in the flag string
The first two descriptors in the list have been expunged,
by Fred's expunging his mailbox on another client. The mail
removes messages 2101 and 2104 from its local copy of mailbox "fred".
The next descriptor in the list is one which Fred marked for
on another client yesterday. The mail reader marks the local
of the message as deleted. The last descriptor in the list is a
one. The mail reader adds the descriptor to its local list.
all changes to mailbox "fred" have now been recorded locally,
update list can be reset
reset-descriptors fred 1 2312
The repository responds with
200 command
indicating that it has removed from "office-client"'s update list
Lambert [Page 23]
RFC 1056 PCMAIL June 1988
messages in mailbox "fred" with UIDs between 1 and 2312 inclusive (
this case just two messages). "Fred" has now been synchronized.
mail reader now turns to Fred's "archive" mailbox and asks for
first ten changed descriptors
fetch-changed-descriptors archive 10
The repository responds with
250 descriptor list follows
.
The zero-length list tells the mail reader that no descriptors
been changed in "archive" since its last synchronization. No
synchronization needs to be performed
Fred's mail reader is now ready to pull over the new message.
message is 320 lines long; there might not be sufficient storage
"office-client" to hold the new message. The mail reader
anyway
fetch-message fred 2312
The repository begins transmitting the message
251 message follows
UID: 2312
From: joe@bar.mit.
To: fred@PTT.LCS.MIT.
Date: Thu, 17 Dec 87 18:24:09
Subject: Another typical subject
Fred
...
Halfway through the message transmission, Fred's workstation runs
of disk space. Because all DMSP operations are defined to
failure-atomic, the portion of the message already transmitted
destroyed locally and the operation fails. The mail reader
Fred that the message cannot be pulled over because of a lack of
space. The synchronization process is now finished and Fred
start reading his mail. The new message that was too big to fit
"office-client" will be marked "off line"; Fred can use the
Lambert [Page 24]
RFC 1056 PCMAIL June 1988
reader to either remote-print it or delete and expunge other
until he has enough space to store the new message
Since Fred is running in interactive mode, changes he makes to
messages will immediately be transmitted into DMSP operations
sent to the repository. Depending on the mail reader implementation
Fred will either have to execute a "synchronize" command
or the client will synchronize for him automatically every so often
7. A current Pcmail
The following section briefly describes a current Pcmail system
services a small community of users. The Pcmail repository
under UNIX on a DEC Microvax-II connected to the Internet.
clients run on IBM PCs, XTs, and ATs, as well as Sun workstations
Microvaxes, and VAX-750s
7.1. IBM PC client
Client code for the IBM machines operates only in batch mode.
make local state changes in a mail reader; the changes are
until the user runs a network client program. The program
to the repository, performs the queued changes, and
local and global mail states. The network client program
disconnects from the repository
The IBM PC client code has gone through several revisions since
first Pcmail RFC was published. What was once a fairly primitive
cumbersome system has evolved into a system that makes excellent
of the PC's limited resources and provides a fairly powerful, easy
to-use mail reader
Users access and modify their local mail state via a mail
written in the Epsilon text editor's EEL extension language.
are given a variety of commands to operate on individual messages
mailboxes, as well as to compose outgoing mail
Synchronization and the processing of queued changes is performed
a separate program, which the user runs as desired. The
takes any actions queued while operating the mail reader,
converts them into DMSP operations. All queued changes are
before any synchronization is performed. The program can be
directly from the mail reader, without having to exit and restart
The limitation of IBM PC client operation to batch mode was
because of development environment limitations. The mail
cannot work with the network code inside it because of the
program architecture. The only solution was to provide a two-
Lambert [Page 25]
RFC 1056 PCMAIL June 1988
client, one part of which read the mail and one part of
interacted with the repository. Although slightly cumbersome,
two-program setup works quite well
7.2. UNIX client
Client code for the Suns, Microvaxes, and VAX-750s runs on 4.2/4.3
UNIX. It is fully interactive, with a powerful mail reader
Richard Stallman's GNU-EMACS editor. Since UNIX-based
have a good deal of main memory and disk storage, no effort was
to lower local mail state size by keeping message descriptors
than message text
The local mail state consists of a number of BABYL-format mailboxes
The interface is very similar to the RMAIL mail reader
present in GNU-EMACS
The mail reader communicates with the repository through network
implemented in EMACS-LISP. Changes to the local mail state
immediately made on the repository; although the repository is fast
there is a small noticeable delay in performing operations over
network
There is no provision for automatic synchronization whenever new
arrives or old mail is changed by another client. Instead,
must get any new mail explicitly. A simple "notification"
runs in the background and wakes up every minute to check for
mail; when mail arrives, the user executes a command to get the
mail, synchronizing the mailbox at the same time
7.3. Repository
The repository is implemented in C on 4.2/4.3BSD UNIX. Currently
runs on DEC VAX-750s and Microvaxes, although other repositories
soon be running on IBM RT machines and Sun workstations.
repository code is designed to allow several clients belonging to
particular user to "concurrently" modify the user's state. A
scheme prevents one client from modifying mail state while
client is modifying the same state
8.
Pcmail is now used by a small community of people at the
Laboratory for Computer Science. The repository design works well
providing an efficient means of storing and maintaining mail
for several users. Its performance is quite good when up to
users are connected; it remains to be seen whether or not
repository will be efficient at managing the state of ten or
Lambert [Page 26]
RFC 1056 PCMAIL June 1988
hundred times that many users. Given sufficient disk storage,
should be able to, since communication between different users
clients and the repository is likely to be very asynchronous
likely to occur in short bursts with long "quiet intervals"
between as users are busy doing other things
Members of another research group at LCS are currently working on
replicated, scalable version of the repository designed to support
very large community of users with high availability.
repository also uses DMSP and has successfully communicated
clients that use the current repository implementation.
therefore seems to be usable over several flavors of
design
The IBM PC clients are very limited in the way of resources.
mail reader/editor combination is quite 