Responses to critiques of the proposed mail protocol
RFC 555

Document Type RFC - Unknown (July 1973; No errata)
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 555 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                               James E. White (JEW)
Request for Comments: 555                                        SRI-ARC
NIC: 17993                                                 July 27, 1973

          Response to Critiques of the Proposed Mail Protocol

   A number of people have responded to my proposal for a Mail Protocol
   (JEW RFC 524 -- 17140,2:y).  In the current RFC, I've attempted to
   collect and respond to the questions, complaints, and suggestions
   that various individuals in the Network community have offered.  I
   intend to critique myself in a forthcoming RFC.

   I hope that dialog on the protocol proposal will continue, and that
   others will join in the discussion.  I will respond via RFC to any
   additional critiques I receive (I hope there'll be many).




         (DHC JBP RFC 539 -- 17644,3g:gy)


         One postulates the existence of AT LEAST ONE host whose Mail
         server process implements the User Verification Function (JEW
         RFC 524 -- 17140,5f7:gy).  Any process can contact that server,
         give him the name of any Individual in the Net and a test Id,
         and the server will determine whether or not the Individual and
         Id agree.

            The NIC, for one, will without question provide this

         With such support available to it, ANY FTP server process can
         then require (of any or all user processes that contact it) an
         ID command wherever it wishes within the user-server
         interchange (within the constraints of the Protocol).  The
         server simply prompts for the Id, gets it, opens a connection
         to the User Verification Agent, presents to it the Individual's
         name and purported Id, receives a positive or negative
         response, and deals with the original user process accordingly.

White                                                           [Page 1]
RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


            Suppose a user process opens a connection to UCLA-NMC's
            server process, invokes the Delivery function, and in the
            course of the interchange identifies the Author as Roberts
            at USC-ISI.

            The implementors at UCLA-NMC's server process chose to
            require proof, in all Delivery transactions, that the Author
            is who he claims he is.  It therefore prompts for an Id in
            response to the AUTHOR command from the user process, and
            receives in return the command 'ID arpawheel <CA>'.

            UCLA-NMC's server then connects to the NIC's server, invokes
            the User Verification function there, specifying 'REQUESTOR
            roberts @ usc-isi <CA>' and 'ID arpawheel <CA>'.  The NIC
            informs UCLA-NMS that the Id is incorrect.

            UCLA-NMC then rejects the original ID command.

         Of course, the Protocol does not require that a server demand
         Ids from users that contact it.  Servers who choose not to
         require proof of identity simply never prompt for ID commands,
         and treat any they receive as NOPs.  For such implementations
         (which represent the current, FTP mail protocol situation), no
         third-part interchanges are ever required.

         Each user in the Net has a single Id that he uses throughout
         the Net for purposes of sending and receiving mail.  That Id
         need not (but may, either coincidentally or by design) have any
         other use.  In particular, a user's Id is independent of the
         passwords by which he gains access to accounts that he might
         possess on hosts around the Net.

            Of course, a user could and might see to it that his
            passwords and Id are the same.  The NIC, for example, might
            require that a user log in to its system with NIC ident and
            Id, rather than with host name and password, as it does

         I emphasize again that Ids have nothing whatsoever to do with
         accounting.  UCLA-NMC doesn't force the Author to prove his
         identity so UCLA has someone to whom it can bill the resources
         consumed in processing the Delivery transaction.  It does so to
         prevent Jim White from authoring a piece of mail and claiming
         that Larry Roberts wrote it.

White                                                           [Page 2]
RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

            UCLA-NMC does have the option of requiring that a user
            process log in before it delivers mail so that it can be
            billed for the resources it uses.  The appropriate commands
            to require of the user process are USER, PASS, and ACCT.
            But, the billing process is separable from that of
Show full document text