> I am not sure exactly what you mean by a "well-managed" anonymous ftp site,
> but I have a true story to relate which should make anyone hesitant to allow
> any kind of anonymous write access via ftp. One Friday one of our users
> asked that we create a special area for one of his collaborators to
> (anonymously) upload some data over the weekend. Being naive, we agreed,
> and created the area. Monday morning we received a call from a co-employee
> on the other side of campus informing us that we were on a published list of
> great FTP sites to obtain (illegal) software. Over the weekend not only had
> some enterprising person found the anonymous site, scanned it for writeable
> directories, set up the warez, and published the address.
>The trick is to save uploaded files without read permission, so people can
upload all the warez they want but nobody will be able to download them.
Of course this requires a person to monitor uploads and dispose of them.
Back to the real problem: how can user A send a big file to user B without
any special access rights to user B's file space?
If you have unattended file reception (queued email, an always-on anonymous
ftp server) with no limits, you're always open to DOS attacks or worse.
But if you have limits, people have no way to send big files to each other.
One way around this, which is not exactly point-and-click, is to set up
an attended transfer. It requires both parties be online at the same time.
Here is a way to do it with C-Kermit (UNIX or VMS) or Kermit 95 (Windows):
http://www.columbia.edu/kermit/
Person A, who wants to receive the file, gives Kermit the following command:
cd somedirectory ; CD to desired reception directory
set host /server * 3000 ; Wait for a connection on TCP port 3000
Person B, who wants to receive the file, gives Kermit the following command:
set host <Person-A-IP-name-or-address> 3000
if fail exit 1 Can't make connection
send <filename>
finish
exit
Any nonprivileged port number can be used. This simple example does not
do anything about authentication or take any safety precautions, but all of
that is possible. For example, the server can forbid all forms of access
except file reception (e.g. so the client can't change directories, upload
to other directories, delete files, overwrite files, etc).
Authentication methods range from none at all, to clear-text passphrase
settable by user A, to Kerberos or SSL/TLS.
Also there is no need for either user A or user B to type commands; Kermit
scripts can be written to automate the process, which no doubt can be hidden
behind some form of GUI if desired.
If anybody is interested in pursuing this approach, I'll be happy to
elaborate.
- Frank