spammer using cancel evading technique

Piotr KUCHARSKI chopin at
Wed Dec 3 01:33:11 UTC 2003

It happened on a moderated pl.rec.humor.najlepsze group.

There was a spam <5E5928B3.97F37DFC at> (with
forged Approved: header, not approved by a group moderator, of course.)
As I help the moderator a little, I was asked to cancel it. 
So I used the usual 'cspam' script and... got surprised. 
The spam was still on the group.

A little investigation revealed, that the spammer sent the following
article first:

 Message-ID: <cancel.5E5928B3.97F37DFC at>
 Control: cancel <gdI4zpG6g3kD.PiS96nsWAl at>
 Date: Tue, 2 Dec 2003 06:39:07 GMT
 NNTP-Posting-Date: Tue, 02 Dec 2003 01:47:12 EST
 X-Trace: lakeread03 1070347632 (Tue, 02 Dec 2003 01:47:12 EST)

And a moment later the real spam:
 Message-ID: <5E5928B3.97F37DFC at>
 Date: Tue, 2 Dec 2003 06:35:53 GMT
 NNTP-Posting-Date: Tue, 02 Dec 2003 01:47:28 EST
 X-Trace: lakeread03 1070347648 (Tue, 02 Dec 2003 01:47:28 EST)
Observe NNTP-Posting-Date and forged Date: fields, as well
as Control: not matching Message-ID: in the first article.

As the cspam script generates M-ID for the cancel control in a form
of <cancel.original.M-ID> and sends it via rnews -- this control was
ignored by the server, as it already had such M-ID in its history.

The situation, where M-ID of <cancel.X> does not mean the cancellation
of <X> is a bit unfortunate.

Tomasz Surmacz suggested that perhaps innd could take care of this
problem, checking whether a post with "Message-ID: <cancel.X>"
also contains "Control: cancel X" and accept it, if so, as this
generates two entries in a history (for X and cancel.X) and
eliminates this problem.

I know that the cspam could generate "cancel2.X" or else,
but that is quite unfortunate incident.


Beware of he who would deny you access to information, for in his
heart he dreams himself your master.   -- Commissioner Pravin Lal  -- polska wersja quizu dla nerdów ;)

More information about the inn-bugs mailing list