spammer using cancel evading technique

Tomasz R. Surmacz tsurmacz at
Thu Dec 4 03:02:52 UTC 2003

Russ Allbery wrote on Wed, Dec 03, 2003 at 06:42:54PM -0800:
> Tomasz R Surmacz <tsurmacz at> writes:
> > Russ Allbery wrote on Tue, Dec 02, 2003 at 06:18:03PM -0800:
> >> Yup, you can definitely do that in a local Perl or Python filter and
> >> it's not a bad idea for inclusion in something like Cleanfeed.
> > But due to the efficiency reasons, wouldn't it be better to include it
> > in actual innd C code?  So far, this is not a big problem, as such
> > pseudo-cancels are not common yet, but I bet they will spread if we do
> > not take some action.
> This is about the most efficient sort of check one could do; I don't think
> you'd really notice the difference.  About the only speed hit you're
> incurring is the creation of the Perl header hash.  I'm hesitant to

Ok, just after sending my previous email, I realized I should have added:

" include it in actual innd C code and make it standard?"
                                        ^^^^^^^^^^^^^^^^^^^^   :-)

> include things like this into the C code because it's hard to change the C
> code, and this is fundamentally a site policy decision (there isn't
> anything special about <cancel.*> message IDs in the specification).

then maybe it should be standarized?  Prohibition of third-party email
relaying is also not specified in any standard dociument, AFAIK, and for
much too long time it was not included in default rules for most MTAs.

The convention of using <cancel.MSGID> allows multiple bots to cooperate
without generating tons of unnecessary messages. But this works on an
assumption, that the cancel message will eventually hit all servers,
from one bot or another. If somebody is poisoning news servers with
fake non-cancel messages, then this method stops working even if you
apply protecting rules to *some* of the servers (the real message will
be kept within islands of "good" servers, blocked from propagation by
the majority of other servers, poisoned with the fake cancel). So this
solution has to be applied globally, before it's too late. Otherwise we
will end up with cancels cancelling those fake cancels and multiple
cancels for real spam messages, consuming even more bandwidth than the
spam message itself.


(_   _' __) Tomasz R. Surmacz PGP Id: 56A1520D tsurmacz bofh,0rg,pl
  |  (__  \ "bash awk tr grep perl sed df du, du-du du-du, vi troff
  |__(____/  su fsck rm * halt LART LART LART!" -- the Swedish BOFH

More information about the inn-bugs mailing list