spammer using cancel evading technique

Jeffrey M. Vinocur jeff at
Thu Dec 4 17:06:12 UTC 2003

On Thu, 4 Dec 2003, Paul Tomblin wrote:

> Quoting Tomasz R. Surmacz (tsurmacz at
> > 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 in
> > > history, but but foo is still uncancelled, it issues a (but
> > > only if 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

More information about the inn-bugs mailing list