RFC491 - What is Free?

王朝other·作者佚名  2008-05-31
宽屏版  字体: |||超大  

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 RFC475, 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

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 RFC451 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 RFCwas put into machine readable form for entry]

[into the online RFCarchives by Helene Morin, Via Genie,12/1999]

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
© 2005- 王朝网络 版权所有