saj@chinet.chi.il.us (Stephen Jacobs) (02/11/91)
In article <1991Feb11.054514.25449@terminator.cc.umich.edu> jon@terminator.cc.umich.edu (Jon Brode) writes: >BART service will no longer be available to access the Atari archive This leaves us back where we were a few months ago. The panarthea archive isn't really an appropriate central depository of 'stuff'; that would impair its function as a newsgroup archive. As long as the enthusiasm and the resources exist at umich.edu, having a central repository there seems like a good idea. But ftp-only leaves a lot of us with pretty weak connections to it. I have a couple of modest suggestions: In the IBM PC world, there's an ftp-only central repository at SIMTEL20. It is shadowed at (at least) 2 other sites, with mail servers at the shadow sites. There's a modest reduction in the disk load at the shadow sites because they can purge 'dead' files and re-fetch them only if needed. Traffic is decentralized. Any volunteers? Another model is the UNIX/misc archives. Basically, they exist at 3 sites, with different access at each (although one of them, sir-alan, has been down for a rather long time). What they have in common, is that the requestor pays the phone bill. Anyone in a position to set up a bbs for the atari archive? A uucp-accessible site? Again, some degree of off-lining might be possible, although automating it might take a bit of effort. With both a bbs program and a uucp-clone having been distributed in this newsgroup, basic software availability should be a non-problem. What all this requires is a couple hundred MB of disk, a cpu and at least one phone line. Ftp access would be desirable, but could be gotten around. The work involved would probably be too much for one person, but reasonable for 2 or more. Does either a shadow server or a second site sound like something someone wants to do? Any user group want to take on a BIG project? I suspect that a bbs with free and fee access levels could be kept from being a hopeless money-sink. Steve saj@chinet.chi.il.us
bright@ccu.umanitoba.ca (Bob Bright) (02/12/91)
In article <1991Feb11.145036.24222@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: >>BART service will no longer be available to access the Atari archive > >This leaves us back where we were a few months ago. The panarthea archive isn't >really an appropriate central depository of 'stuff'; that would impair its >function as a newsgroup archive. As long as the enthusiasm and the resources >exist at umich.edu, having a central repository there seems like a good idea. >But ftp-only leaves a lot of us with pretty weak connections to it. [various suggestions for allowing non-ftp'ers access to atari.archive deleted] Your suggestions are good ones, Stephen, but they all sound like a lot of work. Are you aware that there is a mail server at princeton specifically set up to handle to remote ftp requests and send the files to you by mail? Try sending the one-line message "help" to: bitftp@pucc.princeton.edu (Note: I haven't actually used this server, but I presume that it works, since it's been around for a while. I think that there may be similar servers located elsewhere, but I don't have addresses. Does anyone else have any details on this sort of thing?) BBB -- Bob Bright <bright@ccu.umanitoba.ca> Dept. of Philosophy University of Manitoba Winnipeg, Man R3T 2N2 (204) 474-9680
darius@edm.isac.CA (Darius S. Naqvi) (02/12/91)
In article <1991Feb11.212135.13827@ccu.umanitoba.ca> bright@ccu.umanitoba.ca (Bob Bright) writes: >In article <1991Feb11.145036.24222@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: >>>BART service will no longer be available to access the Atari archive >> >>This leaves us back where we were a few months ago. The panarthea archive isn't [ stuff deleted ] >Your suggestions are good ones, Stephen, but they all sound like a lot >of work. Are you aware that there is a mail server at princeton >specifically set up to handle to remote ftp requests and send the >files to you by mail? Try sending the one-line message "help" to: > > bitftp@pucc.princeton.edu > >(Note: I haven't actually used this server, but I presume that it >works, since it's been around for a while. I think that there may be I've used this server a few times. It works very well. No need to cry about not having ftp access!! -- Darius S. Naqvi mail:darius@edm.isac.ca ISA Corp. uucp:{uunet,alberta}!ncc!isagate!darius Edmonton, Alberta, Canada phone:(403) 420-8081
grahamt@syma.sussex.ac.uk (Graham S Thomas) (02/12/91)
From article <1991Feb11.054514.25449@terminator.cc.umich.edu>, by jon@terminator.cc.umich.edu (Jon Brode): > > Mr. Kaiser probably thought he was really clever when he figured out how > to get around our quota system. Over the course of 4 days, he requested > over 90 files totalling many megabytes. When this came to the attention of > the atari.archive.umich.edu system administrator, he put an end to it. > For good. > Mr. Kaiser's activities are to be deplored, that's for sure. But is it not the also the case that the decision to close the service completely just because of the activities of one abuser is an over-reaction? Now other people are being denied use of the service through no fault of their own. Was there no easy way to fix things so that Mr. Kaiser was denied but not others? I don't want to overreact here myself. I appreciate that any access to atari.archive is a privilege, and not a right. The people who run the service contribute major efforts, voluntarily as far as I know, and it's up to them how they want to run it. I hope that net users don't send flames in the direction of umich. But on behalf of the people who rely on the BART mail service, as I did until fairly recently, could I ask that the decision be reconsidered? In the meantime, if there are any UK users without FTP access who have used BART and who want files (within the fairly tight limits of my quota and the time restrictions of our scratch space), I'd be prepared to fetch them here and then mail them on - provided it can be done quite quickly, as I don't have time to go exploring on other people's behalf. Graham -- Graham Thomas, SPRU, Mantell Building, U of Sussex, Brighton, BN1 9RF, UK INTERNET: grahamt@syma.sussex.ac.uk JANET: grahamt@uk.ac.sussex.syma BITNET: grahamt%sussex.syma@UKACRL UUCP: grahamt%sussex.syma@ukc.uucp Phone: +44 273 678165 Fax: +44 273 685865
david@doe.utoronto.ca (David Megginson) (02/12/91)
In article <1991Feb11.212135.13827@ccu.umanitoba.ca> bright@ccu.umanitoba.ca (Bob Bright) writes: > >Your suggestions are good ones, Stephen, but they all sound like a lot >of work. Are you aware that there is a mail server at princeton >specifically set up to handle to remote ftp requests and send the >files to you by mail? Try sending the one-line message "help" to: > > bitftp@pucc.princeton.edu > There have been many complaints about BITFTP clogging up the net since it went into mail service--originally, it had a binary-only connection with BITNET nodes. Personally, I use bitftp, but NOT on Usenet, only on BITNET. If we overuse bitftp, it will probably disappear soon. So, use it, but check with your sysadmin and/or your feeds first, and use it responsibly. David -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
reid@wrl.dec.com (Brian Reid) (02/13/91)
I am the manager of the USENET and electronic mail gateway between Digital Equipment Corporation and the rest of USENET. The unfortunate incident for which Mr. Kaiser has been so cruelly blamed was completely an accident, and is the result of a "culture clash" rather than any malice. It is perhaps best not to use harsh words until you have finished understanding an incident. Hans Kaiser works in Digital's software support office in Stuttgart, Germany. Like most Digital field offices, it is equipped with VMS computers and connected to Digital's DECNET network. The converstion between internal DECNET and external protocols is performed by the DECWRL computer for which I am responsible. VMS and DECNET do not have the concept of queueing mail. When you send a message, either it is delivered instantly or it bounces. The idea is that you want the sender to know instantly if his message did not get through. As a result, VMS mail users have, through the years, grown accustomed to believing that if they do not get a "message sent" message, then their message did not get sent. Whenever mail is relayed from one network to another, rather than just queued, the concept of "immediate delivery" is somewhat meaningless, because you haven't really delivered the mail, but rather have just handed it off to some intermediate postman. But user expectations are still very strong: if a user sends an internetwork message, and doesn't get back a "message sent" reply, his experience leads him to believe that the message was lost. Last week we had a head crash on the primary disk on our DECWRL relay computer, and for various reasons it took almost 3 days to get the machine back up. We announced this failure on the appropriate internal Digital newsgroups (dec.mail.config), but did not send individual notification to the tens of thousands users of the gateway, as we sometimes do when we are certain that it will be down for a long time. During this interval Hans Kaiser was trying to retrieve files from the Atari archive server. He is not a reader of dec.mail.config and probably did not know that the gateway was down. He sent some retrieval requests, and got no reply. Here comes the "culture clash" that I mentioned in the first paragraph. When a VMS user sends a mail message that does not get delivered, he is conditioned to believe that it has been lost or deleted, because that is what happens in the normal case. However, these messages that Kaiser sent were neither lost, nor deleted. They were carefully queued, waiting for the DECWRL gateway to come back up again, so that they could be sent. When he got no response, Kaiser sent more requests. This is the natural thing to do in the VMS world. If it didn't work, and if you are following instructions, then try again. Maybe something will have been fixed. I don't know exactly how many times Kaiser repeated the request over the 3-day interval, but I am sure that if he had known that his messages were all being queued, instead of vanishing as he thought, that he would not have repeated them. Eventually (I think it was on Wednesday night, California time) the DECWRL gateway was brought back to life, and all of the queued messages were sent to the Atari archive server in one lump. Archive servers are in general programmed to have per-user quotas, so that if something like this happens, it won't bring the archive server to its knees trying to handle so many requests at once. Alas, here the "culture clash" strikes again. The DECNET mail protocol does not support a "time and date" mechanism. The only information that it records about a message, besides the message body, is what we Unix/IP people know as the "To" and "Cc" and "Subject" and "From" fields. In DECNET protocol it is up to the receiver of a message to timestamp it with the time that it was received. The reason for this is that since there is no queueing, the time that a message was received is guaranteed to be equal to the time that it was sent. As a result, the network mail protocol has no mechanism to record the time that a message was sent. The documentation for the DECWRL mail gateway, which we distribute to all employees who ask for it, instructs them to use the gateway by sending mail with a certain mail program that is not part of the software that Digital ships to its customers. This program, called "nmail", is helpful in smoothing the peak load on the gateway by queueing at certain times. However, since the mail-sending software knows that the mail might be queued, it records the time that the message was actually originated. This is because the "Date" field in the message will contain the time that it was delivered and not the time that it was actually sent. "nmail" does this by adding the date and time to the "From" field of the message. It really doesn't have much choice, because the DECNET mail protocol supports only a "To", "Subj", "From", and "Cc" field, and there is a fixed limit to the size of the "Subj" field. Why does this matter? It matters because the Atari archive server at the University of Michigan looks at the "From" field of an incoming message to avoid processing too many simultaneous requests from the same person. There is a "per-user" quota for each day. The problem is that when you send the mail using a mail program that encodes the date and time of the message in the "From" field, then every message looks like it came from a different user. As a result of this, when the DECWRL mail relay came back to life last Wednesday, it sent many dozens of retrieval requests to Michigan all at once, and Michigan's software failed to understand that they were all from the same person because the "From" field on each of them had a different date and time. As a result, the Michigan archive server tried to process all of them at once, and, evidently, melted into a pile of slag. Since I work for a company that sells computers, I suppose the loyal thing for me to do at this point is to try to sell Michigan a bigger computer to use as the archive server, but I don't work in a sales office, I work in Corporate Research, and what I want is for everybody to be happy. I am very sorry that a combination of accidents inside Digital, in Germany and California, caused this unfortunate incident on a university computer at Michigan, and I will happily offer the services of the excellent network programmers at DEC Western Research to help ensure that the Michigan archive server does not meet this fate again. Mostly I want people to know that this was in no way the fault of Hans Kaiser. If it was anybody's fault, it was my fault, for accidentally failing to copy the serial number of a certain disk drive onto a service-contract renewal form for 1991, thereby leaving the disk unprotected by maintenance contract. Disks often fail on purpose when they learn that they are not covered by maintenance contract. If you have sent Mr. Kaiser (or Herr Kaiser, as he probably prefers to be called) a nasty message, it might be civil to send him another one letting him know that, now that the facts are known, you aren't so angry any more. If you find the need to be angry at somebody, please be angry at me. As the manager of an electronic mail gateway, I'm used to it. Brian Reid DEC Western Research Laboratory
silvert@cs.dal.ca (Bill Silvert) (02/14/91)
In article <1991Feb12.165927.21941@pa.dec.com> reid@wrl.dec.com (Brian Reid) writes: >VMS and DECNET do not have the concept of queueing mail. When you send a >message, either it is delivered instantly or it bounces. The idea is that you >want the sender to know instantly if his message did not get through. >As a result, VMS mail users have, through the years, grown accustomed to >believing that if they do not get a "message sent" message, then their >message did not get sent. >Whenever mail is relayed from one network to another, rather than just queued, >the concept of "immediate delivery" is somewhat meaningless, because you >haven't really delivered the mail, but rather have just handed it off to some >intermediate postman. But user expectations are still very strong: if a >user sends an internetwork message, and doesn't get back a "message sent" >reply, his experience leads him to believe that the message was lost. Now the situation is becoming clear. I'm supposed to use a network like that at work, and the experience is a real shock to a Unix-user like me (I hope that isn't called a Unich!). When I send mail to Vancouver, which is 5000 km and 4 time zones away, if my VMS system doesn't connect it does not send the mail. No queuing! No wonder Herr K. got confused. If there is a message in all of this, it is that before we flame individuals in public and pillory them by name, we should send mail and ask for an explanation. Something about a fair trial... -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 UUCP=..!{uunet|watmath}!dalcs!biomel!bill BITNET=bill%biomel%dalcs@dalac InterNet=bill%biomel@cs.dal.ca
gaertner@tertius.in-berlin.de (02/14/91)
Recently Bob Bright talked about BITFTP. Well, I post a copy the Help-file,
but until know I don't have any experience with it.
Maybe any other can try it.
Ralf
----
Ralf Gaertner e-mail: gaertner@venus.rz-berlin.mpg.de
FHI Berlin
BITFTP -- Princeton BITNET FTP Server
(bitftp@pucc.nitnet)
BITFTP provides a mail interface to the FTP portion of the IBM
TCP/IP product ("FAL") running on the Princeton VM system, to allow
BITNET/NetNorth/EARN users to ftp files from sites on the Internet.
To use BITFTP, send mail containing your ftp commands to BITFTP@PUCC
(or to BITFTP@PUCC.Princeton.edu).
The first command to BITFTP must be "FTP", "FTPLIST", "HELP", or
"VMS". If you send BITFTP mail or a message containing only the
command "FTPLIST", it will send you a list of some of the hosts that
allow anonymous ftp. (Note that there is no guarantee that BITFTP
can access all the hosts in that list.) Use "HELP" to request a
current copy of this help file. Use "VMS" to request a collection
of tips provided by BITFTP users on how to handle binary files from
BITFTP on VMS systems.
The recommended syntax for FTP requests is:
FTP hostname NETDATA --or-- FTP hostname UUENCODE
USER username password
<other ftp subcommands>
QUIT
Following the hostname on the FTP command, you may specify
"UUENCODE" or "NETDATA" to tell BITFTP the format in which you wish
to receive files.
If the username is "anonymous", no password is required; BITFTP will
use your userid and nodeid as the password. Note that on many
systems passwords are case-sensitive; that is, the password may be
required to be in lower case or mixed case or upper case. (The same
is true of directory and file names.)
The following is an example of an ftp request:
FTP f.ms.uky.edu NETDATA
USER anonymous
CD /pub/msdos/Games
DIR
BINARY
GET robotron.arc msdos.robotron
QUIT
BITFTP implements a subset of the ftp subcommands provided in the
IBM TCP/IP and uses the same syntax. Therefore, you may find it
useful to obtain the "IBM TCP/IP for VM Command Reference Manual",
IBM order number GC09-1204.
The currently supported subcommands are:
ACCT -- to send host-dependent account information.
format: ACCT account-information
ASCII -- to change the file transfer type to ASCII.
format: ASCII
BINARY -- to change the file transfer type to image.
format: BINARY <FIXED record-len> <VARIABLE>
CD -- to change the working directory.
format: CD directory
CLOSE -- to disconnect from the foreign host.
format: CLOSE
DIR -- to get a list of directory entries.
format: DIR
EBCDIC -- to change the file transfer type to EBCDIC
format: EBCDIC
GET -- to get a file from the foreign host.
format: GET foreignfile <localfile>
If you specify "localfile", it must be in
the forms "filename.filetype" or "filename",
and the filename and filetype may each be no
more than 8 characters long and may not contain
periods.
LOCSTAT -- to display local status information.
format: LOCSTAT
LS -- to list the files in a directory.
format: LS <name>
PWD -- to print the working directory.
format: PWD
QUIT -- to disconnect from the foreign host.
format: QUIT
STATUS -- to retrieve status information from a foreign host.
format: STATUS <name>
SYSTEM -- to get the name of the foreign host's operating
system.
format: SYSTEM
TYPE -- to specify Image, ASCII, or EBCDIC file transfer.
format: TYPE <I!A!E>
BITFTP does not provide a PUT capability, and there is no intention
to make it do so in the future.
BITFTP currently accepts requests only via RFC822-format mail, IBM
NOTE-format mail, PROFS-format messages, or files with no headers at
all. BITFTP currently returns the requested files as NETDATA-format
files or as mail files containing UUENCODED data. If you specify
"UUENCODE" or "NETDATA" on your "FTP" command, BITFTP will attempt
to use that format. If you do not specify the format, BITFTP will
attempt to select the appropriate format for your node.
UUENCODED files are broken up into mail files that contain no more
than 50,000 bytes of data. NETDATA-format files that are larger
than 300,000 bytes are sent in 300,000-byte pieces using the BITSEND
function. You should be able to receive such files using the BITRCV
function available from your nearest NETSERV. (If you do not know
how to use NETSERV, ask your local BITNET/EARN/NetNorth Coordinator
for assistance.) If BITRCV is not available for your system, use
the command you normally use to receive NETDATA-format files and
then concatenate the files in the order shown in the BITRCV control
file to recover the original file.
Users in the UK should note that BITFTP attempts to send
NETDATA-format files through the gateway from EARN into Janet via
the NIFTP facility at Rutherford Lab. Note that receiving files via
NIFTP requires an overt action on your part. If you are at a Janet
node and don't know how to use NIFTP, you should ask for assistance
locally. Alternatively, you can ask BITFTP to send your files
UUENCODED inside mail by specifying the "UUENCODE" option.
If BITFTP sends you a file you cannot read, THE FIRST THING TO DO is
to make sure that you specified ASCII if the file should contain
textual material or that you specified BINARY if the file should
contain binary data, executable programs, tar files, or the like.
VMS users should specify BINARY F 512 and should use RECEIVE/BINARY
to receive the NETDATA-format binary files BITFTP sends them.
If BITFTP sends you a uuencoded file that you cannot uudecode, the
first thing to do is to translate all occurrences of 0x7E in the
file to 0x5E and then try uudecoding again. (Some gateways are
changing 5Es to 7Es when the files pass through them.)
There are many different flavors of UUENCODE/UUDECODE. The version
that BITFTP uses puts a "guard character" at the end of each encoded
line. Most implementations of uudecode know to ignore this
character. If yours does not, then you should remove the last
character of each line before attempting to uudecode the file. Note
that the guard character is not always "M"; the short lines at the
end of the file may have some other guard character, rather than
"M". Whatever that character is, it should be removed (or your
uudecode should be fixed).
When BITFTP is told to transfer a file in FIXED format, such as
"BINARY FIXED 128", it will create a file whose total byte count is
an integral multiple of the record length (128, in this case). This
means that the last record may be padded to get it to the specified
record length. In such a case, you may need to use an editor to
shorten the last record so that the total byte count in the file is
correct. (If the file is uuencoded when you receive it, shorten it
AFTER you have uudecoded it.)
In addition to any files you request, you will also receive a mail
file containing a log of your ftp session. In that mail file,
entries prefixed by ">" are your original commands; those prefixed
by ">>" are your commands as interpreted by BITFTP and passed to
TCPIP; those prefixed by ">>>" are your commands as interpreted by
TCPIP and passed to the remote host; those prefixed by "<<<" are
messages from the remote host; and those prefixed by ">>>>" are
completion messages from BITFTP.
If BITFTP is unable to connect to the host you specify, it will send
you mail after the first attempt, but will keep trying at intervals
over three days. The only additional mail file you will receive
will be when the connection is made successfully or when BITFTP
gives up after three days.
The load on BITFTP is often very heavy, and network backlogs are
often so great that it may take several days for a file to get to
you once BITFTP sends it, so please be patient and don't send
multiple requests for the same file. If your system allows you to
send interactive messages, you can inquire about BITFTP's backlog by
sending the query "How are you?", e.g., on a VM system:
TELL BITFTP AT PUCC How are you?
Questions about BITFTP and suggestions for improvements should be
directed to Melinda Varian, MAINT@PUCC on BITNET or
maint@pucc.princeton.edu on the Internet.
The author gratefully acknowledges the use of the FTP SUBCOM
interface written by David Nessl, the SENDJANI EXEC written by Alan
Flavell, the uuencoding utility written by John Fisher, and the
RFC822 parsing routine written by Eric Thomas. NOTE: If you have
any complaints or suggestions about the way any of these routines
work in BITFTP, please send them to MAINT@PUCC (Melinda Varian), not
to the authors.sgc@robots.oxford.ac.uk (Simon Carling) (02/18/91)
In article <1991Feb17.235832.17444@msuinfo.cl.msu.edu> schultzd@kira.uucp (David Schultz) writes: >What I want to know is "How come people who need mail file service >aren't just sending to Panarthea?" I don't know the address off hand, >but I'm sure someone can post it. If I remember correctly, Panarthea >archives everything that goes through comp.binaries.atari.st. Probably because the comp.{binaries,sources}.atari.st groups are only a fraction of what's available at atari.archive... For UK users who have JANET/PAD access, ftp is now available via nsf.sun at UCL, username and password are both "guestftp". This service is free to academic users (though I expect commercial sites will have to pay - isn't life fun in the ivory tower 8-). Cheers, Si Carling
kentd@FtCollins.NCR.com (Kent.Dalton) (02/19/91)
>What I want to know is "How come people who need mail file service >aren't just sending to Panarthea?" I don't know the address off hand, >but I'm sure someone can post it. If I remember correctly, Panarthea >archives everything that goes through comp.binaries.atari.st. panarthea is a good archive site as well... It only has stuff that's been post to the binaries and sources groups, though. If you want some of the really large stuff like GCC and all the neat Demos on atari.archive that's the only place that has them. I'm really thankful to all the contributors and maintainers of both sites, I've gotten a lot of useful stuff from both! -- /**************************************************************************/ /* Kent Dalton * EMail: Kent.Dalton@FtCollins.NCR.COM */ /* NCR Microelectronics * CIS: 72320,3306 */ /* 2001 Danfield Ct. MS470A * */ /* Fort Collins, Colorado 80525 * (303) 223-5100 X-319 */ /**************************************************************************/ Fortune: Research is what I'm doing when I don't know what I'm doing. -- Wernher von Braun
adamd@rhi.hi.is (Adam David) (02/19/91)
In <1991Feb17.235832.17444@msuinfo.cl.msu.edu> schultzd@kira.uucp (David Schultz) writes: >What I want to know is "How come people who need mail file service >aren't just sending to Panarthea?" I don't know the address off hand, >but I'm sure someone can post it. If I remember correctly, Panarthea >archives everything that goes through comp.binaries.atari.st. Trouble is, plenty of useful stuff didn't get posted on c.b.a.s., or much more recent versions are present on atari.archive@umich. I hope it is possible to resolve the security issue soon so that people with mail-only access are not cut off forever. BitFTP is at best a temporary solution IMHO. Surely it can't be too difficult to rig up a "hacker-proof" mailer quota system. Here's cheers and appreciation for the ST-archivers at umich for providing such matchless and useful service, "probably the best in the world". -- Adam David. adamd@rhi.hi.is
brode@math.lsa.umich.edu (Jon Brode) (02/19/91)
In article <2798@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes: >Surely it can't >be too difficult to rig up a "hacker-proof" mailer quota system. I'm open to any suggestions on how to do an automatic "hacker-proof" quota system. The version I'm testing now closes the hole that was used, but I still know of many easy ways to fool the quota system and no easy way to prevent it. While you're thinking of an automatic system to suggest, keep a few things in mind: - we don't have the administrative time to deal with pseudo-accounts - we can't assume that account names are unique on the internet - there are many, many twisted ways to write valid addresses - some networks use user@host.domain instead of user@domain - some systems let users change their mail names independent of acct name Jon Brode -- brode@math.lsa.umich.edu Supreme Allied Umich Atari Posse Commander
entropy@ai.mit.edu (entropy) (02/20/91)
To:
In article <1991Feb19.154407.4016@math.lsa.umich.edu> brode@math.lsa.umich.edu (Jon Brode) writes:
- we don't have the administrative time to deal with pseudo-accounts
- we can't assume that account names are unique on the internet
- there are many, many twisted ways to write valid addresses
- some networks use user@host.domain instead of user@domain
- some systems let users change their mail names independent of acct name
I haven't been following this thread very closely because I didn't use
BART. But as I understand it, someone dowloaded more than his fair
share, which caused too much of a strain on the system, and caused
someone in administration to shut it down. Why not just put an upper
limit on the amount of resources BART is allowed to use? Like, only
allow it to send 10 files an hour, or perhaps run it at a really low
priority, or something like that. Then if some idiot _does_ break
security and grab hundreds of megs of stuff with one request, the
worst that can happen is everyone else has to wait a few hours (or
perhaps days) and then get their files. This would probably require
some tuning to prevent too much backlog, but it certainly would
prevent an irresponsible user from getting the system shut down again.
entropydavid@doe.utoronto.ca (David Megginson) (02/20/91)
In <1991Feb19.154407.4016@math.lsa.umich.edu>, Jon Brode writes: > In article <2798@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes: > >Surely it can't > >be too difficult to rig up a "hacker-proof" mailer quota system. > > I'm open to any suggestions on how to do an automatic "hacker-proof" quota > system. The version I'm testing now closes the hole that was used, but I > still know of many easy ways to fool the quota system and no easy way to > prevent it. > Perhaps it would be a good idea to do a little monitoring. Have a kill file of accounts which are banned from BART, and a routine in the program to inform you of possible violations (ie. user names match + part of host, etc.). The possible violations list should be small (a few names every week). By looking over the list for about 5 minutes every week, you should be able to figure out who is cheating, and when you have identified a cheater, send them a canned message and add them to the kill file. This way, the computer does most of the work, but you make the final judgement. For example, since my address is david@doe.utoronto.ca you could check for 'david' and 'doe' in the quota file, and it would find variations on this. Likewise, you could have BART report unusually heavy activity from a single host (I might have more than 1 account at doe), and if it looks serious, you could check with the sysadmin to make sure everything's kosher. David -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
bittrolff@evans.enet.dec.com (Steve Bittrolff) (02/21/91)
As I understand it, having followed this situation in several Atari related forums, the entire incident was an ACCIDENT, caused by a new user and an unfortunate disk crash. Without going into details, the user sent in several requests (for the same files) over a period of several days, because he never received any response. The problem was on the server system, which had a bad disk. It did, however, queue up his requests. When the system came back up it sent all of the requests at once with the header reformatted in such a way that the Michigan server did not recognize the requests as coming from the same individual. It seems kind of harsh to shut off all access because of this. It has been running fine until now and barring another accident will probably continue to run fine. Why can't it just be reinstated? Steve ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Steve Bittrolff | bittrolff@pikes.enet.dec.com or | bittrolff@evans.enet.dec.com | | | ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
johnb@churchy.ai.mit.edu (John Bunch) (02/27/91)
What about using bitftp@pucc.bitnet That will allow you to ftp files and have them mailed to you.. Works quite well.... John Bunch -- ************************************************************************ * John Bunch * 610 Morris St. * To be filled with a nifty * * johnb@albert.ai.mit.edu * Albany,NY * quote at a later date... * * * 12208 * * ************************************************************************