RFC 491 (rfc491) - Page 2 of 2

What is "Free"?

RFC 491                       What Is Free                 12 April 1973


   command would be right.  (Presumably, FROM would be followed by
   PASS.)  Being reasonably familiar with one of the systems which does
   allow access control on mailboxes, let me point out how it works:
   permissible "principal identifiers" are placed on the "access control
   list" of the mailbox, and when the mailbox is referenced by a process
   the principal identifier of that process must match (explicitly or as
   a member of a class) an entry on the list or access will be
   forbidden.  But the principal identifier is associated with the
   process at login.  Now, it is probably a valid objection to say that
   accounting should be separated from authentification, but it isn't
   always.  So why invent a redundant mechanism based on the assumption
   that it is?

   Another point on authentication via login: it has been argued that
   FTP mail ought to be so cheap that it "can be buried in overhead" by
   the same token, if it's so cheap it shouldn't bother anybody to login
   on his own account if he wants to prove the mail's from himself.

   To be scrupulous, I should close by mentioning the possibility that
   NETML might be repugnant to some Hosts.  If such be the case, then I
   propose that a new FTP FREE command be introduced so that Servers
   need not recognize MAIL as an implicit login.  The reasons here are
   at least twofold: First, it appears that when the "subcommands" to
   MAIL get worked out, some of them will have to precede the MAIL (or
   users will set awfully tired of typing their names, etc.); therefore,
   the list of commands which imply a login grow and grow and Server
   FTP's will have to change and change.  Second, if MAIL implies a
   login, it will be hard in some environments to get the arguments
   across to the process created on behalf of the mailer (and it is not
   a good idea at all to assume that the mailing can be handled by the
   process which is listening on socket 3).  Even introducing a new
   mechanism (and see RFC 451 for my strong feelings against that sort
   of step in general) in FREE seems better than making all the
   assumptions that the loginless alternative does.

   Note that an alternative to this whole line of reasoning would be
   simply to observe that the FTP is internally inconsistent in that it
   acknowledges on the one hand (in the definition of the USER command)
   that some systems may require USER / PASS and then (mis)states on the
   other hand (in the discussion of mail) that they may not.  If this
   abstract point is more satisfying to some readers than the foregoing
   pragmatic argument, well and good.


          [This RFC was put into machine readable form for entry]
     [into the online RFC archives by Helene Morin, Via Genie,12/1999]





Padlipsky