rfc524.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,976 行 · 第 1/5 页

Network Working Group                                           J. White
Request for Comments: 524                                        SRI-ARC
NIC: 17140                                                  13 June 1973


                         A Proposed Mail Protocol

AUTHOR'S INTENT

   This is the document I offered in (15146,) to write.  It's a proposed
   specification for handling mail in the Network -- a Mail Protocol.

   Main handling is currently implemented as two FTP commands, MAIL and
   MLFL, which permit an FTP user process to deliver a file or string of
   text to an FTP server process, designating it as mail to be made
   available to a user, identified by a local name, in its host.  The
   protocol proposed here is much richer than that, both in terms of the
   functions it supports, and in terms of the flexibility it provides.

   Although one can (I think) and might, implement software on the basis
   of this document, this REALLY IS a Request for Comments.  Comments,
   questions, position papers are solicited.  There are, I'm sure, bugs
   in the protocol specified here, and I hope that readers will point
   them out via RFC as they discover them.

   Various members of the Network community have, during the last few
   months, pointed out to me specific inadequacies in the existing mail
   commands and asked me to be conscious of them in designing a new
   protocol.  I've tried to do that.  If anyone feels that his concern
   wasn't properly dealt with here, or that it slipped through the
   cracks entirely (for which I apologize in advance), I would
   appreciate it if he would prod me once more.

INTRODUCTION

   THE MAIL PROTOCOL ENVIRONMENT

      The Mail Protocol (MP) is implemented by Mail user and server
      processes, in keeping with the model for previous high-level
      protocols.  The Mail user and server processes are further
      specified to be also FTP user and server processes, respectively.
      That is, MP is implemented as a set of commands accessible from
      within the FTP command space.

      The MP command set is defined to lie conceptually within a
      subsystem, invoked from the FTP command space with the command
      MAIL <CFLF>.




White                                                           [Page 1]

RFC 524                 A Proposed Mail Protocol            13 June 1973


         NOTE:  Since a command called 'MAIL' already exists within the
         FTP command space, the command name 'XMAIL' might substitute
         for 'MAIL' while the current mail commands are being phased
         out.

      The MP command set may or may not (according to the implementation
      of a particular server) be implemented by a process distinct from
      that which implements FTP proper.

      The following are implications of the 'subsystem' concept, of
      which the reader (and implementer) must be aware:

         (1) Names of MP commands are known only within the MP
         subsystem.  MP commands must (and should naturally) be rejected
         by the server if the user process presents them outside of the
         subsystem.

         (2) Exit from the Mail subsystem (to the FTP command space) is
         effected with and only with the command EXIT <CRLF>.  FTP
         commands must be rejected by the server if the user presents
         them while inside the subsystem (i.e., before EXIT is issued).

         (3) The same command name may be assigned without ambiguity to
         two entirely different commands, provided that one lies within
         the FTP command space and the other within MP, the two being
         distinguishable by their contexts.  MP and FTP therefore do not
         compete for command names, and MP command names may be chosen
         without regard for the environment in which the subsystem
         resides.

         NOTE:  It so happens that there are commands DEFINED within MP
         which duplicate the functions of FTP commands and bear the same
         names.  The effective result is that some commands are
         explicitly allowed within MP.  The reader will understand that
         this fact is consistent with the conventions described in 1-3
         above, and that no ambiguities result.

      The subsystem concept (if not the name 'subsystem') is taken from
      Mike Padlipsky's Unified User Level Protocol (UULP), which the
      author of the present document strongly supports.  The fact that
      MP is accessed from FTP, rather than both FTP and MP being
      accessed independently from a more general executive program, is
      simply a concession to the fact that FTP is widely implemented and
      UULP isn't.  The author hopes that protocol development will, in
      the near future, begin to proceed along the lines exemplified by
      UULP.





White                                                           [Page 2]

RFC 524                 A Proposed Mail Protocol            13 June 1973


      MP conforms to FTP in general syntax.  In particular, commands and
      their responses are strings of NVT characters; command names are
      limited to four or fewer, upper- or lower-case, alphameric
      characters, and are terminated by the character SP; commands are
      generally terminated with the TELNET New Line sequence (CR LF);
      command responses contain both numeric (process readable) and text
      (human readable) portions.  Both reader and implementer are
      referred to the FTP protocol document for a detailed description
      of such matters; no attempt has been made to duplicate the
      discussion in the present document.

      The FTP protocol document assigns those replies whose second digit
      is '6' to RJE functions.  In like manner MP appropriates those
      reply codes whose second digit is '7' for reporting results
      peculiar to its functions.  It is, however, the author's position
      that FTP, MP, and the RJE protocol are all best implemented as
      subsystems under a common UULP executive, in which case a single
      subset of the reply space could be used unambiguously by all three
      protocols (and any yet to be defined), since every reply would
      implicitly be qualified by the name of the subsystem from which it
      emanates.

   THE MAIL MODEL

      MP defines mail to be text communicated between users (both human
      and processes) in less that (but ideally approaching) real time.
      The definition excludes so-called console-to-console
      communication, where users exchange information at the character
      or line level.

      Pieces of mail are characterized by such attributes as title,
      content, author, and recipient.  A piece of mail may be a one- or
      two-line message sent from one individual to another, a draft of a
      document sent by one individual to a design group for review, a
      polished, formal document sent from one group to another, a
      message sent to a human user by a process (e.g., an RJE server
      process might notify a user by Network Mail when his job has
      completed), etc.  All such forms of communication are mail and are
      supported by MP.

      Pieces of mail can be forwarded from one location to another

      Pieces of mail can be replied to.

      The identity of the author of a piece of mail can be verified,
      avoiding forgery and misrepresentation.





White                                                           [Page 3]

RFC 524                 A Proposed Mail Protocol            13 June 1973


      Pieces of mail can be permanently recorded, assigned a long-term
      identifier by which they can be forever be retrieved for
      reference, and entered in catalogs.  And access to such recorded
      mail can be restricted to a specified subset of the user
      community.

      Some hosts accept mail whose recipients reside elsewhere in the
      Network, and assume responsibility for delivering the mail to them
      (worrying about retrying delivery when hosts are down, etc.), and
      acknowledging its delivery to the sender.

      The picture being painted for the reader is one in which processes
      cooperate in various ways to flexibly move and manage Network
      mail.  The author claims (without proof, of course) that the
      picture will in the future get yet more complicated, but that the
      proposal specified here can be conveniently enlarged to handle
      that picture too.

ORGANIZATION OF THIS DOCUMENT

   The rest of this document consists of the following components:

      GLOSSARY

         The concepts introduced briefly in the section above are more
         formally defined, and their manner of representation in the
         protocol specified.

      MP FUNCTIONS

         The command sequence is defined by which a user process
         initiates each of the logical functions (e.g., Distribution,
         Recording, Delivery) which can be performed by a Mail server
         process.

      EXAMPLE

         An example of the command-response exchange between a user and
         server is given.

      COMMAND SUMMARY

         A summary of MP commands is given.

      COMMAND REPLIES

         Reply code assignments are given and briefly explained.




White                                                           [Page 4]

RFC 524                 A Proposed Mail Protocol            13 June 1973


      FORMAL SYNTAX

         The formal syntax of the command language is specified.

   In all sections but the last (i.e., the formal syntax presentation),
   verbose keyword forms are employed, in the interests of clarity.
   These verbose forms have no existence anywhere but in this document;
   in implementing a Mail user or server process, the terse keyword
   forms which appear in the formal syntax presentation are to be
   employed

GLOSSARY

   Terms are listed here in alphabetical order.  Words or phrases which
   appear in the definitions with initial letters capitalized are
   themselves formally defined elsewhere in the glossary.

   ACCESS LIST (for a piece of Recorded Mail)

      That set of individuals with access to a piece of Recorded Mail,
      and for each such individual, the type(s) of access granted to
      him.

      An Access List is represented in the Protocol as a series of
      command pairs (juxtaposed in the command stream), each pair
      consisting of an ACCESS command followed immediately (and
      optionally) by an ACCESSTYPES command.  Each pair of commands
      corresponds to one individual in the set.

         ACCESS <individual> <CA>

         ACCESSTYPE <accesstypes> <CA>

            Command arguments identify the Individual to whom access is
            granted, and specify the kind(s) of access allowed him.
            Either Read Access, Controlling Access, or both may be
            granted.

            If no Individual is specified, All is implied.  In the
            absence of an explicit ACCESSTYPES command, one with only
            Read Access specified is to be assumed.

         In the absence of an explicit Access List, one granting Read
         Access to All and Controlling Access to the Author(s) and the
         Clerk is to be assumed.






White                                                           [Page 5]

RFC 524                 A Proposed Mail Protocol            13 June 1973


   ACKNOWLEDGMENT (for a piece of Mail)

      A form of Unrecorded Mail, generated by a Distribution Agent,
      whose Recipient is the Monitor for a previous piece of Mail, which
      acknowledges Delivery -- successful or otherwise -- to the
      Recipient(s) of that first piece of Mail.

      An Acknowledgment bears the Serial Number of the Mail it
      acknowledges, as the Reference Serial Number.

   ACKNOWLEDGMENT CONDITION (for Acknowledgments)

      The attribute of an Acknowledgment which determines the
      circumstances under which it will be generated by the Distribution
      Agent.

      The following Acknowledgment Conditions are defined:

         ALWAYS

            Acknowledgment is given when all Deliveries are complete,
            regardless of whether or not they are all completed
            successfully.

         FAILURE

            Acknowledgment is given when all Deliveries are complete if
            and only if Delivery to one or more Recipient(s) fails.

         NEVER

            An Acknowledgment is never made.

      An Acknowledgment Condition is represented in the Protocol by the
      command:

   ACKCONDITION <ackcondition> <CA>

      In the absence of an explicit ACKCONDITION command, one with an
      argument of FAILURE is to be assumed.

   ACKNOWLEDGMENT TYPE (for Acknowledgments and Progress Reports)

      The attribute of an Acknowledgment or Progress Report which
      determines the nature of its Content.






White                                                           [Page 6]

RFC 524                 A Proposed Mail Protocol            13 June 1973


      The following Acknowledgment Types are defined:

         TERSE

            The Content of a TERSE Acknowledgment or Progress Report is
            specified by the Protocol to be an unembellished list of the
            Mail's Recipient(s), and the current Delivery Status for
            each (except that those Recipient(s) whose Delivery Status
            is SUCCESSFUL shall not be included in the list).

            The Content of a TERSE Acknowledgment is one or more
            instances of the following:

               <deliverystatus> <individual> <CRLF>

            TERSE Acknowledgments and Progress Reports are intended to
            be process-readable.

         VERBOSE

            The Content of a VERBOSE Acknowledgment or Progress Report
            is not specified by the Protocol, but might include a list
            of those Recipient(s) to whom the Mail could not be
            delivered and why, the times at which Delivery was made to
            others, etc.

            VERBOSE Acknowledgments and Progress Reports are intended to
            be human-readable.

      An Acknowledgment Type is represented in the Protocol by the
      command:

         ACKTYPE <acktype> <CA>

      In the absence of an explicit ACKTYPE command, one with an
      argument of TERSE is to be assumed.

   ALL

      Every conceivable Individual.

   AUTHOR (of a piece of Mail)

      An Individual (there may be more than one) given formal
      recognition for having authored a piece of Mail.






White                                                           [Page 7]

RFC 524                 A Proposed Mail Protocol            13 June 1973