pst@comdesign.uucp (Paul Traina) (05/18/88)
No one has commented (positive or negative) to my ideas on hacking a 'squelch' control message into news 2.11. Either my message did not get out, or no one cares if someone intentionally or accidentally creates a pseudo-virus on the net? To re-hash my suggestion: The implementors of the cancel control message wanted to avoid unnecessary traffic, so they designed several features into it: If a cancel message arrives before the original message, it goes into the bit-bucket. (a) it is not propigated (b) no action is taken I am in favor of a second form of cancel, more powerful than the original cancel message (with the drawback of creating more net traffic). If the squelch message makes it to a site that already has the "target" message to be killed, it behaves just like "cancel". However, if the target message is not yet there, it will: (a) place a fake entry into the history log (so when the new message *does* arrive, it will be dumped into the bit-bucket. (b) propigate to all usenet neighbors (c) the originating inews should put a 2 week expiration date on the cancel message (I'm paranoid about having "squelch" turn into a problem itself -- this is probably not necessary). Why is this important? It would have been *much* easier to kill the recent misc.test and alt.test postings that caused havoc on a number of systems. We could have called a couple of backbone sites and placed a squelch message on them, and they in turn would have propigated the squelch message before the original message got to 99% of the net. As is, with the 'cancel' system, all one could do is send a pitiful (and late) cancel message out to follow (but never quite catch up) with the original posting. When is squelch to be used? It's not a cancel -- it's to stamp out messages when it's urgent. It generates more net traffic than a cancel, so it should *only* be creatable by news administrators. Well, what do you think? I'm trying to shed some light on the subject so we have some tools to combat USENET terrorism (especially when it's accidental). I'd appreciate suggestions & comments either pro-or-con. Paul -- Paul Traina, Systems Software Architect suddenly my feet are feet of mud, ComDesign | Network Equipment Technologies it all goes slow-mo. pst!comdesign@pyramid.com i don't know why i'm crying, ucbvax!pyramid!comdesign!psti am i suspended in gaffa? --kate
kre@munnari.oz (Robert Elz) (05/18/88)
In article <279@comdesign.UUCP>, pst@comdesign.uucp (Paul Traina) writes:
< If a cancel message arrives before the original message, it goes into the
< bit-bucket.
< (a) it is not propigated
< (b) no action is taken
What version of news do you have? It must be ancient. In any recenty
version of news at all (from 2.10, and probably 2.9 and before) cancel
messages don't behave that way at all.
< However, if the
< target message is not yet there, it will:
< (a) place a fake entry into the history log (so when the new
< message *does* arrive, it will be dumped into the bit-bucket.
< (b) propigate to all usenet neighbors
This is what cancel does.
krejerry@oliveb.olivetti.com (Jerry Aguirre) (05/19/88)
In article <279@comdesign.UUCP> pst@comdesign.uucp (Paul Traina) writes: >If the squelch message makes it to a site that already has the "target" >message to be killed, it behaves just like "cancel". However, if the >target message is not yet there, it will: > (a) place a fake entry into the history log (so when the new > message *does* arrive, it will be dumped into the bit-bucket. But cancel already does! Cancel control messages already do fake the history so that the canceled message will be rejected if it arrives later!
brad@looking.UUCP (Brad Templeton) (05/19/88)
I dunno. If you're planning a quick call to various backbone sites, any dummy message with the same article-id as the nasty message should do the trick. The dummy message will propagate on normal channels (possibly use a distribution of news.config which is supposed to have extra links) anywhere the real message hasn't arrived. If it gets somewhere the real message is, it will stop there, but I'm assuming that the message has already made it out. Of course this gets very tough to coordinate with a cancel, since a cancel crossing paths with the dummy would cancel the dummy, and on a batched news system, stop it from travelling. This isn't great, but it would work now. To solve this you create a control distribution for dummy messages that is widespread, moves fast and is NOT batched. (In fact, even invoke uux without waiting if you want!) This would work without any software changes. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
dg@lakart.UUCP (David Goodenough) (05/20/88)
From article <279@comdesign.UUCP>, by pst@comdesign.uucp (Paul Traina): > No one has commented (positive or negative) to my ideas on hacking a > 'squelch' control message into news 2.11. Either my message did not > get out, or no one cares if someone intentionally or accidentally creates > a pseudo-virus on the net? [ Discourse on squelch deleted ] I like the idea, I would speak in favour of it with the CAVEAT that like moderated newsgroup information, it has to be approved by one of the backbone sysadmins. I put up this CAVEAT, because the damage that could be done by unregulated use of such a feature does not bear thinking about. Also if done correctly it could help stamp out a lot of vast postings (listen to the pot calling the kettle black :-) I just put 22K in comp.os.cpm :-) got my asbestos suit on) - I for one would be prepared to pay for a long distance phone call to a backbone - either voice or for uucp xfer. (I just checked spaf's posting and I don't have to call L.D. - husc6 and mit-eddie are both withing spitting distance, and linus isn't too far) -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!adelie!cfisun!lakart!dg +-+-+ | +---+
pst@comdesign.uucp (Paul Traina) (05/25/88)
In article <2124@munnari.oz>, kre@munnari.oz (Robert Elz) writes: < In article <279@comdesign.UUCP>, pst@comdesign.uucp (Paul Traina) writes: < < If a cancel message arrives before the original message, it goes into the < < bit-bucket. < < (a) it is not propigated < < (b) no action is taken < < What version of news do you have? It must be ancient. In any recenty < version of news at all (from 2.10, and probably 2.9 and before) cancel < messages don't behave that way at all. You were right 1/2, I was right 1/2. A history log entry is made, but the message is not canceled. < < However, if the < < target message is not yet there, it will: < < (a) place a fake entry into the history log (so when the new < < message *does* arrive, it will be dumped into the bit-bucket. < < (b) propigate to all usenet neighbors < < This is what cancel does. Wrong. With all due respect, please examine your source code. I am (as of this week) now running news211 patch level 14, and cancel does not propigate. Perhaps you are running something newer?