rfc993.txt

RFC 相关的技术文档

Clark & Lambert                                                 [Page 5]

RFC 993                                                    December 1986


   A descriptor holds the following information: the message UID, the
   message size in bytes and lines, four "useful" message header fields
   (the "date:", "to:", "from:", and "subject:" fields), and sixteen
   flags.  These flags are given identifying numbers 0 through: 15.
   Eight of these flags are reserved for the repository's use.  Some of
   these are actually used by the repository, while others are simply
   held for informational purposes.  In the current repository implemen-
   tation these flags mark:

      - (#0) whether it has been deleted

      - (#1) whether the message has been seen

      - (#2) whether it has been forwarded to the user

      - (#3) whether it has been forwarded by the user

      - (#4) whether it has been filed (written to a text file
        outside the repository)

      - (#5) whether it has been printed (locally or remotely)

      - (#6) whether it has been replied to

      - (#7) whether it has been copied to another mailbox

   The remaining eight flags are reserved for future use.

   Descriptors serve as an efficient means for clients to get message
   information without having to waste time retrieving the message from
   the repository.

3.2. Repository-to-RFC-822 name translation

   "Address objects" provide the repository with a means for translating
   the RFC-822-style mail addresses in Internet messages into repository
   names.  The repository provides its own namespace for message iden-
   tification.  Any message is uniquely identified by the triple (user-
   name, mailbox-name, message-UID).  Any mailbox is uniquely identified
   by the pair (user-name, mailbox-name).  Thus to send a message
   between two repository users, a user would address the message to
   (user-name, mailbox-name).  The repository would deliver the message
   to the named user and mailbox, and assign it a UID based on the re-
   quested mailbox's next available UID.

   In order to translate between RFC-822-style mail addresses and repo-
   sitory names, the repository maintains a list of address objects.
   Each address object is an association between an RFC-822-style ad-
   dress and a (user-name, mailbox-name) pair.  When mail arrives from
   the Internet, the repository can use the address object list to
   translate the recipients into (user-name, mailbox-name) pairs and



Clark & Lambert                                                 [Page 6]

RFC 993                                                    December 1986


   route the message correctly.

4. Communication between repository and client: DMSP

   The Distributed Mail System Protocol (DMSP) is a block-stream proto-
   col that defines and manipulates the objects mentioned in the previ-
   ous section.  It has been designed to work with Pcmail's single-
   repository/multiple-client model of the world.  In addition to pro-
   viding typical mail manipulation functions, DMSP provides functions
   that allow easy synchronization of global and local mail states.

   DMSP is implemented on top of the Unified Stream Protocol (USP),
   specified in MIT-LCS RFC-272.  USP provides a reliable virtual cir-
   cuit block-stream connection between two machines.  It defines a
   basic set of data types ("strings", "integers", "booleans", etc.);
   instances of these data types are grouped in an application-defined
   order to form USP blocks.  Each USP block is defined by a numeric
   "block type"; a USP application can thus interpret a block's contents
   based on knowledge of the block's type.  DMSP consists of a set of
   operations, each of which is comprised of one or more different USP
   blocks that are sent between repository and client.

   A DMSP session proceeds as follows: a client begins the session with
   the repository by opening a USP connection to the repository's
   machine.  The client then authenticates both itself and its user to
   the repository with a "login" operation.  If the authentication is
   successful, the user performs an arbitrary number of DMSP operations
   before ending the session with a "logout" operation (at which time
   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 are
   failure-atomic.  Failure of any DMSP operation must leave both states
   in a consistent, known state.  For this reason, a DMSP operation is
   defined to have failed unless an explicit acknowledgement is received
   by the operation initiator.  This acknowledgement can take one of two
   basic forms, based on two broad categories that all DMSP operations
   fall into.  First, an operation can be a request to perform some mail
   state modification, in which case the repository will acknowledge the
   request with either an "ok" or a "failure" (in which case the reason
   for the failure is also returned).  Second, an operation can be a re-
   quest for information, in which case the request is acknowledged by
   the repository's providing the information to the client.  Operations
   such as "delete a message" fall into the first category; operations
   like "send a list of mailboxes" fall into the second category.

   Following is a general discussion of all the DMSP operations.  The
   operations are broken down by type: general operations, user opera-
   tions, client operations, mailbox operations, address operations,
   bboard operations, and message operations.




Clark & Lambert                                                 [Page 7]

RFC 993                                                    December 1986


4.1. General operations

   The first group of DMSP operations perform general functions that
   operate on no one particular class of object.  DMSP has two general
   operations, which provide the following services:

   In order to prevent protocol version skew between clients and the re-
   pository, DMSP provides a "send-version" operation.  The client sup-
   plies its DMSP version number as an argument; the operation succeeds
   if the supplied version number matches the repository's DMSP version
   number.  It fails if the two version numbers do not match.  The ver-
   sion number is an unsigned quantity, like "100", "101", "200".  The
   "send-version" operation should be the first that a client sends to
   the repository, since no other operation my work if the 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 NIC
   RFC-822.  The repository takes the message and distributes it to the
   mailboxes specified on the "to:", "cc:", and "bcc:" fields of the
   message header.  If one or more of the mailboxes exists outside the
   repository's user community, the repository is responsible for hand-
   ing the message to a local SMTP server.

   An OK is sent from the repository only if the entire message was suc-
   cessfully transmitted.  If the message was destined for the Internet,
   the send-message operation is successful if the message was success-
   fully transmitted to the local SMTP server.

4.2. User operations

   The next series of DMSP operations manipulates user objects.  The
   most common of these operations are "login" and "logout".  A client
   must perform a login operation before being able to access a user's
   mail state.  A DMSP login block contains five items: (1) the user's
   name, (2) the user's password, (3) the name of the client performing
   the login, (4) a flag telling the repository to create a client ob-
   ject for the client if one does not exist, and (5) a flag set to TRUE
   if the client wishes to operate in "batch mode" and FALSE if the
   client wishes to operate in "interactive" mode.  The flag value al-
   lows the repository to tune internal parameters for either mode of
   operation.

   The repository can return either an OK block (indicating successful
   authentication), a FAILURE block (indicating failed authentication),
   or a FORCE-RESET block.  This last is sent if the client logging in
   has been marked as "inactive" by the repository (clients are marked
   inactive if they have not connected to the repository in over a
   week).  The FORCE-RESET block indicates that the client should erase
   its local mail state and pull over a complete version of the
   repository's mail state.  This is done on the assumption that so many



Clark & Lambert                                                 [Page 8]

RFC 993                                                    December 1986


   mail state changes have been made in a week that it would be ineffi-
   cient to perform a normal synchronization.

   When a client has completed a session with the repository, it per-
   forms a logout operation.  This allows the repository to perform any
   necessary cleanup before closing the USP connection.

   A user can change his password via the "set-password" operation.  The
   operation works much the same as the UNIX change-password operation,
   taking as arguments the user's current password and a desired new
   password.  If the current password given matches the user's current
   password, the user's current password is changed to the new password
   given.

4.3. Client operations

   DMSP provides four operations to manipulate client objects.  The
   first, "list-clients", tells the repository to send the user's client
   list to the requesting client.  The list takes the form of a series
   of (client-name, status) pairs.  The status is either 0 (inactive) or
   1 (active).

   The "create-client" operation allows a user to add a client object to
   his list of client objects.  Although the login operation duplicates
   this functionality via the "create-this-client?" flag, the add-client
   operation is a useful means of creating a number of new client ob-
   jects while logged into the repository via an existing client.  The
   create-client operation requires the name of the client to add.

   The "delete-client" operation removes an existing client object from
   a user's client list.  The client being removed cannot be in use by
   anyone at the time.

   The last client operation, "reset-client", causes the repository to
   mark all messages in the user's mail state as having changed since
   the client last logged in.  When a client next synchronizes with the
   repository, it will end up receiving a complete copy of the
   repository's global mail state.  This is useful for two reasons.
   First, a client's local mail state could easily become lost or dam-
   aged, especially if it is stored on a floppy disk.  Second, if a
   client has been marked as inactive by the repository, the reset-
   client operation provides a fast way of resynchronizing with the re-
   pository, assuming that so many differences exist between the local
   and global mail states that a normal synchronization would take far
   too much time.

4.4. Mailbox operations

   DMSP supports five operations that manipulate mailbox objects.
   First, "list-mailboxes" has the repository send to the requesting
   client information on each mailbox.  This information consists of the



Clark & Lambert                                                 [Page 9]

RFC 993                                                    December 1986


   mailbox name, total message count, unseen message count, and "next
   available UID".  This operation is useful in synchronizing local and
   global mail states, since it allows a client to compare the user's
   global mailbox list with a client's local mailbox list.  The list of
   mailboxes also provides a quick summary of each mailbox's contents
   without having the contents present.

   The "create-mailbox" has the repository create a new mailbox and at-
   tach it to the user's list of mailboxes.  An address object binding
   the (user-name, mailbox-name) pair to an RFC-822-style address is au-
   tomatically created and placed in the repository's list of address
   objects.  This allows mail coming from the Internet to be correctly
   routed to the new mailbox.

   "Delete-mailbox" removes a mailbox from the user's list of mailboxes.
   All messages within the mailbox are also deleted and permanently re-
   moved from the system.  Any address objects binding the mailbox name
   to RFC-822-style mailbox addresses are also removed from the system.

   "Reset-mailbox" causes the repository to mark all the messages in a
   named mailbox as having changed since the current client last saw
   them.  When the client next synchronizes with the repository, it will
   receive a complete copy of the named mailbox's mail state.  This
   operation is merely a more specific version of the reset-client
   operation (which allows the client to pull over a complete copy of
   the user's global mail state).  Its primary use is for mailboxes
   whose contents have accidentally been destroyed locally.

   Finally, DMSP has an "expunge-mailbox" operation.  Any message can be
   deleted and "undeleted" at will.  Deletions are made permanent by
   performing an expunge-mailbox operation.  The expunge operation
   causes the repository to look through a named mailbox, removing from
   the system any messages marked "deleted".

4.5. Address operations

   DMSP provides three operations that allow users to manipulate address
   objects.  First, the "list-address" operation returns a list of ad-
   dress objects associated with a particular (user-name, mailbox-name)
   pair.

   The "create-address" operation adds a new address object that associ-
   ates a (user-name, mailbox-name) pair with a given RFC-822-style
   mailbox address.

   Finally, the "delete-address" operation destroys the address object
   binding the given RFC-822-style mail address and the given (user-