spammer using cancel evading technique
Tomasz R. Surmacz
tsurmacz at ict.pwr.wroc.pl
Fri Dec 5 02:32:54 UTC 2003
Paul Tomblin wrote on Thu, Dec 04, 2003 at 08:41:36AM -0500:
> 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.
> > 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 use the
> cancel.MSGID convention.
I am not proposing to block all cancels.
The checking algorithm should work as follows:
If (message has ID of <cancel.XXX>)
it must also have "Control: cancel <XXX>" header
drop it and do not store in history
Normal cancels will not be affected by this rule at all.
OK - maybe the right place is to put it in the Perl filtering rules.
But to make it work, is should be the default behaviour of all the news
servers, otherwise we will end up with islands of servers doing this
<cancel.*> verification, surrounded by default servers not doing it and
preventing real cancel.* messages from reaching the net.
This change is going to take some time, so it is better to do it while
<cancel.*> abuse is not commonly used by spammers yet.
(_ _' __) Tomasz R. Surmacz, Work:(071)3202636, tsurmacz @ict.pwr.wroc.pl
| (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *-* Home: ts@ wroc,apk,net
|__(____/ "GPF is a registered trademark of Microsoft, Inc."
More information about the inn-bugs