It's finally become necessary (several years later than expected,
actually) to modify the convention used for message-ids of spam
cancels. While the method of preempting the $alz cancel has been used
on relatively rare occasions in the past, usually for isolated
spamming or flooding incidents, the method is currently being used in
conjunction with large-scale ordinary spamming.

Accordingly, myself and several of the other significant despammers
have modified our procedures as follows: instead of using just
<cancel. for the prefix, we now use <cancel.XXXX. where XXXX is a
16-bit number expressed in hex. The procedure for calculating this is
deterministic (all of us will use the same value for any given cancel)
but is not predictable (we hope) by anyone not knowing the algorithm
and shared secret, which will be distributed on a need-to-know basis.

The initial "<cancel." was deliberately kept because of the existence
of configuration options causing such IDs to be refused on the
assumption that they are spam-cancels. Sites that are using INN's
message-id filter to refuse cancels for already-rejected articles will
need to make appropriate changes to their code.

This does, however, break the approach of adding the $alz message-id
to history when rejecting an article. That unfortunately can't be
helped; it's exactly this predictability of the cancel message-id
which needs to be avoided.

--
Andrew.

"I believe we've been over this before.  There isn't need for any sort
 of security feature unless some asshole wants to make a nuisance of
 himself."  Matt (ARPAVAX:glickman) in net.rumor, Dec 1981