spammer using cancel evading technique

[Jeffrey M. Vinocur]

On Thu, 4 Dec 2003, Paul Tomblin wrote:

> Quoting Tomasz R. Surmacz (tsurmacz at ict.pwr.wroc.pl):
> > Paul Tomblin wrote on Wed, Dec 03, 2003 at 10:06:34PM -0500:
> > > So somebody needs to make a smarter bot that if it sees cancel.foo in
> > > history, but but foo is still uncancelled, it issues a cancel_1.foo (but
> > > only if cancel_1.foo isn't in the history as well).
> > 
> > This will only escalate problem with race between bots creating more
> > cancel messages and spammers creating more forged cancels.

And forces the bot to run on the same machine as the server, and leaves a 
race condition in terms of the time it takes to generate the cancel 
message locally.


> > Making sure that <cancel.MSGID> really cancels <MSGID> otherwise it is
> > not accepted, will solve it permanently.
> 
> But that will lock out non-bot cancels.  Self cancels don't obey the
> <cancel.MSGID> convention.

That's actually not a problem.  The OP wants only to prohibit non-cancel 
messages from masquerading as bot-generated cancels because this allows 
spammers to neutralize the bot; user cancels that have random Message-IDs 
are not subject to that sort of attack in the first place.

I agree with Russ that a Perl filter is the appropriate place for this (in 
fact, Cleanfeed may already have something along those lines; it does a 
lot of cancel processing).


-- 
Jeffrey M. Vinocur
jeff at litech.org