diff options
Diffstat (limited to 'doc/rfc/rfc491.txt')
| -rw-r--r-- | doc/rfc/rfc491.txt | 115 |
1 files changed, 115 insertions, 0 deletions
diff --git a/doc/rfc/rfc491.txt b/doc/rfc/rfc491.txt new file mode 100644 index 0000000..c604a15 --- /dev/null +++ b/doc/rfc/rfc491.txt @@ -0,0 +1,115 @@ + + + + + + +Network Working Group M. A. Padlipsky +Request for Comments: 491 MIT-Multics +NIC: 15356 12 April 1973 + + + What Is Free + + In at least three of the RFC's about "mail" and the File Transfer + Protocol (RFC's 454, 475, 479), something very like the following is + asserted: "Network mail should be free; i.e., no login or USER + command should be required." Unfortunately, "i.e" (=that is) is + misleading. It simply does not follow to imply that the only way + mail can be free is for it not to require a login; explicit login on + a free account would of course also work. Indeed, depending upon + per-Host idiosyncrasies in the Logger / Answering Service / process + creation environment, an explicit login may well prove to be far more + natural than an implicit login. (Even in environments where implicit + login is easy, surely explicit login is just easy.) Granted, login + on a free account requires users to remember the name of the free + account. However, this would not be too great a burden to bear if + there were reasons for preferring an explicit login and if the free + account had the same name on all Hosts. Therefore, from the promise + that Network protocols should not implicitly legislate "unnatural" + implementations for participating Hosts if it is conveniently + avoidable, I propose the following formulation: + + Network mail should be free. Network mail should not require + users to remember the name of the free account on a given system. + I.e., it should either be "loginless" or it should take the same + login everywhere. But some systems need/want/prefer a login. + Therefore, USER NETML / PASS NETML should be made to work + everywhere for free mail. + + Note: "NETML" is fewer than six characters and is upper case + hence, it should fit in the least common denominator category + of user identifiers, but it's still long enough not to conflict + with anybody's initials (in all probability). + + Now, because of the implementation implications this may all sound + like special pleading, but I claim that another implication of the + "incorrect" formulation will further show the superiority of an + explicit login for mail. For the "loginless" view leads to problems + in regard to the authentication aspects of login and the accounting + aspects, by apparently assuming that the sole purpose of login is to + initiate accounting. In RFC 475, the problem is exposed when, after + noting that some systems allow access control to be applied to + mailboxes, it is asserted that FTP USER command is wrong for access + control because you'd then be on the free account and a new FTP FROM + + + +Padlipsky [Page 1] + +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 [Page 2] + |