RFC 221 (rfc221) - Page 2 of 5

Mail Box Protocol: Version 2

Alternative Format: Original Text Document

< Previous
Next >

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.


< Previous
Next >

Web Standards & Support:

Link to and support eLook.org Powered by LoadedWeb Web Hosting
Valid XHTML 1.0!Valid CSS!eLook.org FireFox Extensions