[Operators] chatroom flooders

David Banes david at banes.org
Fri Jun 22 15:24:52 UTC 2012

On 22/06/2012, at 4:20 PM, Peter Saint-Andre wrote:

> On 6/22/12 6:16 AM, Peter Saint-Andre wrote:
>> On 6/22/12 4:01 AM, Tim Schumacher wrote:
>>> At Thu, 21 Jun 2012 21:00:45 -0700,
>>> Ed - 0x1b, Inc. wrote:
>>>> On Thu, Jun 21, 2012 at 9:50 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>>>> Hash: SHA1
>>>>> It seems that many of those who run multi-user chat services have
>>>>> experienced chatroom flooders. What best practices do people have for
>>>>> fighting this? It seems the best we can do in real time is change the
>>>>> room to moderated so that new flooders can't send messages, but that's
>>>>> not a very good solution and we should be able to come up with
>>>>> something better. I've been thinking about ways to use entity
>>>>> reputation (XEP-0275), but other suggestions are welcome. :)
>>>>> Peter
>>>> How about tar-pitting the flooders - like OpenBSD's spamd? (and not
>>>> the spam filter spamd)
>>>> It has a good feature set. I like that it works out at the firewall.
>>> Tarpitting sounds good, the problem I can see that in heated
>>> discussion this could also trigger.
>>> Another Problem I see with tarpitting is when the flooder joins with
>>> 10 or more bots tarpitting would not be very effective.
>> And that's what happens.
> Does spamd work by blocking IP addresses?
> One challenge we have is that we can't block a flooder's JID based on IP
> address. All we can do is report the flooder to its "home" server and
> ask that server to disable the account or block future registrations
> from that IP address. For this we need an incident handling protocol
> <http://xmpp.org/extensions/xep-0268.html> and we need it to be widely
> implemented and deployed.

Just chipping in here, speaking from many years experience in the anti-spam industry, it's perfectly acceptable to block the IP address in the even if it impacts other users. The general thought process is that the domain or IP range 'owner' is the responsible party because often it's not actually a 'user' but  a trojan or bot causing the problem so they need to clean up their network.


email, xmpp: dbanes at cleartext.com
UK mobile: +44 782 5138 214
Au mobile: +61 411 747 821

Email Filtering by Cleartext a Carbon Minimised company - www.cleartext.com

More information about the Operators mailing list