Ircd spam filter

[Diane Bruce]

Hi,
Guess I'll dive in here somewhere in the thread.

Something like you asked for, was done on dalnet. It would scan each
and every PRIVMSG looking for a CTCP then see if a DCC send was being done,
censor what got sent. Considering the size of each dalnet server, this
is a horrific load.

The simple answer is really, yes, it is possible.

The problem we keep tripping over, is how to generalise such things. Early
bot catching code used to examine the gecos field for "bot like" strings.
This got generalised into Xlines. The extra delay/CPU only happens
at registration time then.

One could easily modify hybrid to add a check for one particular nasty
string. If your net is small, you'd not notice the load at all. However,
what if tomorrow you need to look for some other CTCP type string?
Then, Adams idea, of an external filter is good. Something you can configure
on the fly. But then, you start adding filter after filter eventually
you will notice it. This has already happened with the "silence on ban"
hack that was added to hybrid. With a large ban list, the delay _is_
noticeable. Think of how much worse it would be to add filters to
each and every privmsg!

It is a very difficult balancing act in hybrid, between adding mis-features
and features that carry enough benefit to make them worth while adding.
Our prime focus has always been "clean, easy to debug, fast code." Others
have taken their own approach. I'd personally rather hybrid did not end
up looking like "unreal-ircd." (This is what Bill was alluding to.)

My suggestion is, to find a coder with some spare time and add it yourself.
Contribute it back to us, we will put it in contrib. The major problem
is, we _cannot_ support whats in contrib. If it breaks, well, its
not supposed to be our fault. ;-) In practice, we have had made exceptions
to clean buggy contrib code. *ugh*  ;-)

I hope this has helped.

- Diane/Dianora