Xref: utzoo comp.mail.uucp:6528 tor.general:2724 ont.general:2569 can.uucp:328 Path: utzoo!utgpu!news-server.csri.toronto.edu!smoke.cs.toronto.edu!moraes Newsgroups: comp.mail.uucp,tor.general,ont.general,can.uucp From: moraes@cs.toronto.edu (Mark Moraes) Subject: Re: BITFTP grief! Message-ID: <91May18.002523edt.1028@smoke.cs.toronto.edu> Organization: Department of Computer Science, University of Toronto References: <1991May15.042146.29800@iguana.uucp> Date: 18 May 91 04:25:45 GMT Lines: 38 stanley@phoenix.com (John Stanley) writes: > No! This is a valuable service to the entire UUCP community. Well, at >least it is here. Ironic. It was intended for the Bitnet community (who play by different rules and have size grading on files, er, virtual card decks). I agree that it would be a valuable service for uunet/uupsi/your-favourite-internet-uucp-service-provider to make a mail based archive service available for their directly connected customers. (I thought uunet already did this) Take that up with them. (I just hope they implement it to cope with several hundred people simultaneously requesting the X.V11R5 distribution :-) Most complaints about mail based archive servers (MBAS) come from the people who provide free uucp connections to their neighbours to improve mail connectivity or because they're nice folk who think a global network is A Good Thing. Usually these people two or three hops upstream from the eventual destination of the MBAS mail. The difficulty is both disk space and modem time tied up by large file xfers. UUCP isn't packet switched, alas. Not much flow control either. Picture all those files from the MBAS piling up behind a Telebit which is the 100Kbps -> 10Kbps chokepoint! At present, we keep logs on MBAS traffic and send "please don't route this mail through us" messages to people who are recipients of a lot of such traffic. It seems to be working fairly well, except for the occasional glitch (the mail Jim was complaining about passed through us too!) and the human cost in monitoring the logs. An option we're considering is to modify our mailer to downgrade messages greater than M Kbytes and remove downgraded messages if they're older than N hours. (may as well learn from Bitnet :-) More human cost, but then, one of utai's postmasters is interested in exploring the frontiers of mailer science! Mark. -- "Coping with Mail Based Archive Servers" -- coming soon to a thesis near you.