Proposed Mail Protocol
RFC 524

Document Type RFC - Unknown (June 1973; No errata)
Last updated 2016-01-28
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 524 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text