From: Brad Templeton (firstname.lastname@example.org)
Date: Sat Jul 11 1998 - 02:44:35 CDT
On Fri, Jul 10, 1998 at 10:02:27PM -0700, Russ Allbery wrote:
> The only real use for early cancels is spam cancellation. I was under the
> impression that we were going to be providing some completely different
> method of dealing with spam and that cancels were going to go back to
> being for individual articles, in which case this isn't an issue. None of
> those sorts of cancels are likely to arrive before the article, and if
> they do, if we have some sort of way of identifying cancels from the
> message ID, the obvious choice is to just refuse them and not add them to
> the history file so that after you get the article (if you get the article
> at all, given that the cancel beat it) if you're lucky you'll get the
> cancel again.
I do hope you are not serious. I can't see us signing off on a system with
an obvious flaw like this from a race condition.
It is not at all uncommon for individual article cancels to arrive
before the article, or for articles to arrive out of order in general.
Look at your own spools, you see this every day. They can arrive
just one second later because of who knows why. It happens and you can't
assume it won't.
I would bet a good chunk of cancels are issued very shortly after the
article, which makes this happen a lot.
The solution is not super hard for either mode. If you get a cancel
first, you record the message-id, the author (or the cancel lock) in
a simple database that gets cleared out every couple of days. You record
this as a magic entry in the history file, to be precise.
This magic entry does not bar articles from being sent to you like a normal
one. When an article does arrive you pull up the entries, compare with
the cancel, and verify the cancel. if it checks out, discard the article.
If it does not, discard the cancel and replace the history entry with a
The digest system does eliminate this, but it is not the most important