Mail Box Protocol: Version 2
RFC 221

Document Type RFC - Unknown (August 1971; No errata)
Obsoleted by RFC 278
Obsoletes RFC 196
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 221 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          R. Watson
Request for Comments: 221                                        SRI-ARC
NIC: 7612                                                 25 August 1971

                     A Mail Box Protocol, Version-2


   Initial reaction to RFC 196, "A Mail Box Protocol", NIC (7141,)
   indicates general agreement on the need for such a mechanism.  The
   conventions suggested in RFC 196 assumed only the use of the Data
   Transfer Protocol (in NIC 7104) in order to simplify an initial
   implementation.  The valid argument, we believe, has been made that
   sites will also implement the File Transfer Protocol and that as much
   as possible the Mail Box Protocol should be a subset of it.  This
   version is in answer to this suggestion.

   The purpose of a mail box protocol is to provide at each site a
   standard mechanism to receive sequential files for immediate or
   deferred printing or other uses.  The files for deferred printing
   would probably be stored in intermediate disk files, although details
   of how a file is handled, stored, manipulated, or printed at a site
   are not the concern of this protocol.

   A mail box, as we see it, is simply a write only (from the Network)
   sequential file to which messages and documents are appended,
   separated by an appropriate site dependent code.

   It is also assumed that there would be a program at the sending site
   which sends the file in the format given below with the optional
   control codes when appropriate.  This program could probably be
   accessed as a subcommand of the Telnet program.

   The motivation for developing this protocol is the Network
   Information Center's (NIC) need to be able to deliver messages and
   documents to remote sites, and to be able to receive documents for
   cataloging, redistribution, and other purposes from remote sites
   without having to know the details of path name conventions and file
   system commands at each site.  Multiple mail boxes (256) are allowed
   at each site and are identified as described below.  The default is
   mail box number 0 for use with the standard mail printer defined

   The only place where the Mail Box Protocol has a potential conflict
   with the File Transfer Protocol is in file naming conventions.  The
   File Transfer Protocol assumes that the using site will use a
   filename which follows the access and file path name conventions of

Watson                                                          [Page 1]
RFC 221               MAIL BOX PROTOCOL, VERSION-2        25 August 1971

   the serving site and that this information would be supplied by the
   user.  In the Mail Box protocol we would like not to have to
   explicitly know the path name conventions at each site.

   In other words there is a need for a network virtual pathname
   convention.  We did not want to solve this problem in general at this
   time and in RFC 196, NIC 7141, proposed the use of a separate socket
   for mail type delivery and the use of an integer 0-127 to specify the
   address of a specific file (Mail Box) to be appended to as the
   simplest form of network-wide standard file name convention for an
   initial implementation.

   To follow more closely the spirit of the File Transfer Protocol, I
   would now recommend the Append Request be specifically used and that
   the standard socket agreed on for use with the File Transfer Protocol
   also be used.  Following the byte indicating an Append request, there
   would be a standard agreed-upon string of letters followed by a
   number, indicating that this is a mail box append request.  A
   suggested name string would be NETMAIL#, where # is a byte
   interpreted as a mail box number 0-255.  If the above suggested Mail
   Box file naming convention is unsuitable and some other network-wide
   standard mail box naming can be agreed on, then it can be used.
   Please let me know how you feel about this naming convention.

   Given agreement on a standard mail box pathname, then the Mail Box
   Protocol can utilize a subset of the File Transfer Protocol
   conventions to be given below.

   The other problem which was raised about the Mail Box Protocol was
   the possibility of someone accidentally or deliberately flooding the
   printer of a site with garbage, as there are no access or file size
   controls.  Some thinking and discussions of this problem have yielded
   no simple satisfactory solutions.  I would recommend initial
   implementations without standard special safeguards in this area.
   Safeguards would be a site-dependent option.  Standard safeguards for
   the above problem can be easily added later if they really prove
   necessary and satisfactory ones can be agreed on.

Watson                                                          [Page 2]
RFC 221               MAIL BOX PROTOCOL, VERSION-2        25 August 1971
Show full document text