Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!smart From: smart@ditmela.oz (Robert Smart) Newsgroups: comp.protocols.tcp-ip Subject: Re: (none) Message-ID: <7752@ditmela.oz> Date: 29 Oct 89 03:40:24 GMT References: <8910290319.AA16276@ucbvax.Berkeley.EDU> Reply-To: smart@ditmela.oz.au (Robert Smart) Organization: CSIRO, Division of Information Technology, Australia Lines: 72 In article <8910290319.AA16276@ucbvax.Berkeley.EDU> randall@uvaarpa.virginia.edu writes: > > The problem of someone somewhere else filling up a node's > spool partition is to my mind serious, as is the ability of users > on a given node to "send" files to themselves and thus get > disk storage space that isn't part of their account's quota > (both are known problems at BITNET sites). > This is all fairly fanciful. In the Australian system the mail message that you get when someone has sent you files says "you have been sent the following files, if you don't retrieve them quickly they'll be automatically deleted". And the system manager can delete them sooner if he likes: the user will realise what has happened if he tries to retrieve the files and they are gone, and he knows who sent them so he can request a resend. Not a good place for the user to store his own files though. > > The Australian notion of a batch-oriented "getfile" application > sounds interesting and could probably be implemented without > too much trouble on the Internet for anonymous ftp if someone > were so inclined... Bit hard to see how you do it without having the batch sendfile mechanism to go with it. Somebody suggested a writeable area reachable by anonymous ftp as the internet-style solution: you stick the files there and send the recipient mail. This is a real security problem. Between when you put the file there and when the recipient receives it, someone else could overwrite it with another file. Since binary files, and programs in particular, are a significant application of this sort of facility, this seems very dangerous. However it has the seeds of a good idea which wouldn't require any new TCP/IP services. The first observation is that an ftp daemon doesn't have to service a real file system -- it can, particularly for anonymous ftp, appear to service a file system which is actually imaginary: a virtual file system. I suggest that after anonymous ftp to a machine there will be a subdirectory of the top level with name "users". If you CWD to users then you will see a lot of subdirectories, one for each user of the machine. If you CWD to one of these you will find a directory which is empty (always empty!) which you can PUT files into. If you PUT files there then it will actually go into a spool area, and the recipient (the directory name) is sent mail requesting that he retrieve the file. The mail will say who sent the file using the password response to the login, plus giving the machine name derived by backtranslation from the calling address. The mail message should indicate that the sender's name is not securely determined. Note that if another person sends you a file with the same name you would have two files that you can retrieve: you can change the name of one or put them in different directories, there is no problem caused by this. The client side of this process can easily be done by a program instead of by an actual person. This gives the opportunity for both sendfile and getfile actions to result in file transfers taking place at times of low computer and network load: like the middle of the night. For example you want to retrieve some files from an anonymous ftp site. You ftp there, when you see the file you want, instead of saying "GET file" you say "DELAY file" (or somesuch). The ftp daemon then remembers your request and that night it will connect to your machine's anonymous ftp, CWD into your directory and put the file there for you to retrieve in the morning. This assumes that you gave your username as password correctly. Bob Smart or P.S. When should I give my address as instead of the "%" hack. I have decided that a reasonable time to switch would be when there is MX-mail software for all major TCP/IP implementations. Anybody like to comment on how close we are to that situation?