From: Brad Templeton (email@example.com)
Date: Mon Jul 27 1998 - 19:20:17 CDT
On Mon, Jul 27, 1998 at 06:41:24PM -0500, Don Croyle wrote:
> Brad Templeton <firstname.lastname@example.org> writes:
> > True, but this only helps deal with the size of the queue. You are not saved
> > from having to keep the queue and all the complexities. Of course that's
> > true for almost all systems.
> With a cancel lock system, all you really need to keep around is the
> message ID of the article, the cancel key(s) the control message
> carried and a timestamp. A signed cancel would need the message
> ID(s), the identity of the key used, some indication of why we should
> trust the signer and a timestamp.
No, all you need for a signed cancel is the identities, presuming signed
cancel is verified via E-mail address.
> Variations on the standard history database would probably suffice for
> both, so there wouldn't be any need to hold on to the actual cancel
> message for any great length of time.
Sadly with current cancel volume many cancels arrive for articles that never
arrive, because people tend to overpropagate cancels to be on the safe side.
So you end up having to keep a lot -- you need to keep these for a few
days, and your full expire time just to be safe.
This is true for any cancel-lock system, and for cancels signed by
the author. For PK signed cancels signed by a 3rd party, or the site,
you can usually execute immediately, putting the stub in the history file
and being done with it.