jbuck@epimass.EPI.COM (Joe Buck) (05/19/88)
Neither Paul Traina nor Robert Elz are quite right about what
"cancel" does when the cancel control message arrives at a site
before the article that is to be cancelled. Paul's "squelch"
message isn't the same as the current "cancel", but its effect
can be achieved by a Supersedes: message.
Paul proposes that a dummy entry in the history file be written
for the cancelled article. Robert points out, correctly, that
2.11 news already does this (2.10.2 news did not do this; I don't
know if it was a 2.10.3 or a 2.11 invention).
The dummy entries look like this:
<1000@epifoo.epi.com> 05/18/88 15:15 cancelled
But Robert is incorrect in assuming that the cancel message is then
passed to downstream sites; it isn't. I was under the same
impression, but I just re-read control.c. A cancel message is only
sent downstream if it actually succeeded in cancelling an article; if
the cancel message arrives first, a blocking entry is stored in the
history file but the cancel message doesn't propogate.
If the cancel message were proprogated as Paul proposes (and as
Robert and I thought it was) a very nasty form of attack would be
possible -- completely shut down a site by posting a series of cancel
messages. For example, if the most recent article out of this site
was <2100@epimass.EPI.COM>, you could post messages cancelling
articles <n@epimass.EPI.COM> for n from 2100 through some large
number, making sure that "epimass" appears on the path somewhere.
The articles wouldn't reach my site (so we wouldn't know we'd been
zapped), but they'd go nearly everywhere else, preventing articles
from me from being accepted. Since a cancel message that arrives
ahead of an article doesn't spread, you can only affect one site by
doing this.
There is a new type of control message that behaves very much
like the "squelch" message Paul proposes: any article with a
"Supersedes:" header. It spreads everywhere, cancels an article
at any site where it exists, and puts a blocking entry in the
history file at any site where it doesn't exist.
Unfortunately, "Supersedes:" wasn't added until 2.11 patch level 10,
and quite a few important sites are running earlier versions.
Patchlevel 8 is quite popular because of its stability; some bugs
were introduced in later patches, but we're running level 14 and
haven't had problems.
Hmm... just thought of a few neat "Supersedes:" tricks. I'm not
telling though ... :-)
--
- Joe Buck {uunet,ucbvax,sun,<smart-site>}!epimass.epi.com!jbuck
Old Internet mailers: jbuck%epimass.epi.com@uunet.uu.net
Argue for your limitations and you get to keep them. -- Richard Bachkre@munnari.oz (Robert Elz) (05/21/88)
In article <2115@epimass.EPI.COM>, jbuck@epimass.EPI.COM (Joe Buck) writes: > But Robert [that's me .. kre] is incorrect in assuming that the cancel > message is then passed to downstream sites; it isn't. Joe is right, beats me how I managed to miss that. Now I guess I should go back through ancient news sources and see from where I picked up the wrong assumption. kre
henry@utzoo.uucp (Henry Spencer) (05/22/88)
> ... a very nasty form of attack would be > possible -- completely shut down a site by posting a series of cancel > messages. For example, if the most recent article out of this site > was <2100@epimass.EPI.COM>, you could post messages cancelling > articles <n@epimass.EPI.COM> for n from 2100 through some large > number, making sure that "epimass" appears on the path somewhere. However, this doesn't work against the increasing number of news systems that use less-predictable message-ids. Take a look at the id on this one, for example -- C News sites are safe against this kind of attack, and we're not the only ones using date-based message-ids.