From wang!elf.wang.com!ucsd.edu!tcp-digest-relay Sat Feb 2 15:26:33 1991 remote from tosspot Received: by tosspot (1.63/waf) via UUCP; Sat, 02 Feb 91 12:01:18 EST for lee Received: from somewhere by elf.wang.com id aa23673; Sat, 2 Feb 91 15:26:32 GMT Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP id AA24433; Sat, 2 Feb 91 09:19:50 -0500 Received: by ucsd.edu; id AA00943 sendmail 5.64/UCSD-2.1-sun Sat, 2 Feb 91 04:30:31 -0800 for jbloom Received: by ucsd.edu; id AA00932 sendmail 5.64/UCSD-2.1-sun Sat, 2 Feb 91 04:30:20 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -ftcp-digest-relay tcp-digest-list Message-Id: <9102021230.AA00932@ucsd.edu> Date: Sat, 2 Feb 91 04:30:16 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@ucsd.edu Subject: TCP-Group Digest V91 #31 To: tcp-group-digest@ucsd.edu TCP-Group Digest Sat, 2 Feb 91 Volume 91 : Issue 31 Today's Topics: budlist (2 msgs) FCC Citation MORE Help needed Just don't care... multiple routes (2 msgs) Undeliverable mail Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 1 Feb 91 18:39 GMT From: Subject: budlist To: tcp-group@ucsd.edu Just a comment on the budlist idea. I don't like it, probably for not very objective reasons. But really, I think that it is the wrong approach to the problem, (the right approach being that the FCC should not prosecute the auto-forwarding systems, just the instigator of the message). I get a fair quantity of hate mail on my system from some guy who appears to be in south Denver who never uses the same call twice. He is almost certainly licensed (he knows too much to be otherwise) but he would regard any budlist mechanism with derision as would, I believe, anyone prone to abusing the system in the first place. Just random wafflings... I'll keep quiet from now on... (about this topic, anyway) Doc ------------------------------ Date: Fri, 1 Feb 91 17:26:22 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: budlist To: DEVANS%COLOLASP.BITNET@CUNYVM.CUNY.EDU, tcp-group@ucsd.edu Doc, You are certainly right as I pointed out. If someone wants to beat the system then they will. My other point though is that if we put in methods to TRY to eliminate the problem then at least in the eyes of the FCC we trying to comply. If the station uses a bogus call then they are going against even more regulations. I would certainly welcome any other methods, other than reading through the volume of mail that goes thru some of these BBS's. Doug ------------------------------ Date: Fri, 1 Feb 91 10:31:30 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: FCC Citation MORE To: tcp-group@ucsd.edu It appears now that the station responsible for the citations being issued has had a long history of causing problems in this area. Both on voice and packet. What I would like to see (maybe it would show the FCC an effort is being made) A budlist mechanism in the NOS BSS. All incoming BBS login's are compared to a disk lookup. This could BE ftpusers or maybe a completely different file. It must function on ax25 connects as this is where the problem would exist. This should also be implemented on ALL bbs programs. Granted this could be done in the bbs community with the TNC's budlist, but much more flexibility would be achieved with it built into the bbs software. This is obviously not the entire answer, but it would go a long way towards eliminating the problem and at least show the powers to be that an effort is being made. The offending (locked out) station could just use a different (illegal) call. There is NO foolproof system. If someone wants to get in and cause a problem they can and will. We just need to make it harder. Keep in mind that anyone running nos with the bbs activated could have the same problem that Tom and the others had. Doug ------------------------------ Date: Fri, 1 Feb 91 15:58 GMT From: Subject: Help needed To: tcp-group@ucsd.edu > all mail gets addressed to ampr.org. Yes! Please, what causes this. I don't have the problem at my location, but one local station does; he's had to go back to an old version. I took a quick loook in all the obvious files (rewrite, domain.txt, whatever) and there wasn't anything immediately obvious. He had spaces instead of tabs, but he tells me that changing to tabs made no difference. Ta muchly Doc ------------------------------ Date: Fri, 1 Feb 91 18:56:58 GMT From: Luca Bertagnolio -- IK2OVV Subject: Just don't care... To: tcp-group@ucsd.edu Gareth et al, this guy from Novara is considered nothing in the Amateur IP "lobby" ;-) here in Italy; he usually floods the packet network with BASIC programs for the C64 and other useless stuff. So, just don't care... :-) I am the sysop for I2AYL packet BBS, and I see too many messages coming from him; fortunately his home BBS is down, and he has no other close BBS to send his mail from. 73, Luca IK2OVV ------------------------------ Date: Fri, 1 Feb 91 15:53 GMT From: Subject: multiple routes To: tcp-group@ucsd.edu The problem with only caching the incoming information is, I think, that it relies on the OTHER guy to tell you about what path to use. If NOS doesn't ever iniate such checking itself of which is the best route, then NOS, all by its lonesome, will never update any routes. It will, rather, rely on real-live people trying the alternatives first. In order for NOS to be "intelligent" itself then I think that it must do a certain amount of "sniffing" for itself. "Flooding" sounds a bit strong a term for it, because I suspect that most of us most of the time would only have at most two reasonably plausible routes to any given host. A couple of pings along two paths once an hour or so shouldn't be a problem as far as channel usage is concerned, I wouldn't have thought. But I'm glad that the issue has re-arisen, because I'd really like somebody to try something...anything... (and not necessarily today :-) :-) :-) ) 73 -- Doc ------------------------------ Date: Fri, 01 Feb 91 13:54:21 MST From: Bdale Garbee Subject: multiple routes To: tcp-group@ucsd.edu > A couple of pings along two paths once an hour or > so shouldn't be a problem as far as channel usage is concerned, I > wouldn't have thought. Tried doing it lately on the path between you and me? If you can get a packet through at all, I'd be impressed... but I digress... :-( Bdale ------------------------------ Date: Fri, 1 Feb 91 17:34:17 +0100 From: adam%TNOAL1.TNO.NL@CUNYVM.CUNY.EDU Subject: Undeliverable mail To: Packet-radio@UCSD.Edu, tcp-group@ucsd.edu Hello all, Sorry for this unusual message, but someone has tried to send me a mail, which had a wrong header. Usually mail from 'strangers' is mail from readers of this bulletin, that's why I'm posting this here. The mail came from: @cis.ohio-state.edu> which clearly has a syntax-error in it. To the writer of this mail: try sending it to: adam@tnoal1.tno.nl or: gaalen@tno.nl You may have added something like @cunyvm.xxx.xx and I've seen one more case in which it failed. I'll confirm receipt as soon as it gets to me! 73 de Adam PA2AGA ------------------------------ End of TCP-Group Digest ******************************