[Operators] Update on spammy invites

Simone Marzona simone.marzona at carnialug.net
Thu Mar 21 14:21:41 UTC 2013

Hello to the list,

> In the email world, neglecting to prevent misuse of your SMTP submission 
> service results in your SMTP servers getting blacklisted.  You don't get 
> off the blacklist until after you've proven that the abuse has stopped.
> What makes chat any different?

I think that there are some similarities with the "old" email world,
that we could evaluate to face this problem.

Blacklists (and over the years, ip reputation services) were/are used to
classfy some ip/subnets in "bad guys" and "good guys".

It often happened that for some reason if one single ip was sending spam
messages all around than an entire c-class network was blacklisted...
This was not funny for legitimate senders.

Traslating this behaviour to xmpp chat services, there is another aspect
of interest:

email is a super fast exchange of writings.., but chat is for "realtime"

What if if your xmpp chat server is blacklisted for just some day even
if your users didn't do evil (cit) ?


> Due to the (apparent) fact that there is no system for XMPP operators to 
> identify abusing services, Google is now assuming that *every* service 
> is a threat.
> If we want Google to stop lumping the good services with the bad, then 
> there needs to be a maintained public blacklist.

or some kind of reputation list... that could be thinked as an evolution
of old-style blacklist wich was a 0/1 status.


> The reality is that the whole of the clients haven't implemented spam 
> protection; much less implemented it consistently.  Given reality, how 
> can we say that client-side anti-spam presents any solution to this problem?

I think that in a spamming behaviour we can't trust users preferences.
If they do spam, they will disable antispam features of xmpp clients, or
they will use a client that has not this feature enabled.

We need to enforce some policy on the server side.

> The XMPP service that our team runs has around 1200 active users, and 
> they all use a different client of their choosing.  There is no way to 
> effective protect our users from spam.  Not to discredit Gajim, telling 
> them to use a different client won't fly.

I do agree with this...

> Around the year 2000, client-side email spam filters were very popular, 
> and they worked pretty well.  But client-side filters only work for 
> savvy users.  If client-side filters are so effective in stopping spam, 
> then why does essentially every email service now implement server-side 
> spam protection?

...you can't trust users. Moreover if you're administering a xmpp
service you DO NOT TRUST your users.

Now some what if..

- create some basic rate policy for specific message types (invites..)

- use some Bayes rule to parse message content. Dirty job: some kind of
pipe to spamc/spamd.. just like we did on old email servers.. (ok ok..
performance problem ahead, difficult to parse file transfer, video/audio
stream, otr-featured, and so on..)

- some year ago I found that some University in UK used to log every
message exchanged (the user was informed with a banner/service announce
at logon time) for future analisys: could this be some kind of spam

Open registration of users, in my opinion, is not the problem, and it
isn't similar to open smtp.
The problem is how to manage the user data AFTER registration: some kind
of auto blocking of users based on chat behaviour, messages type/rate
sent/received.. and so on..

Simone Marzona

Linux registered user number: 509183

PGP key ID: 0FB52D76

Battlestar Galactica - Intro:

"...They look and feel human,
some are programmed to think they are human
there are many copies...
...and they have a plan."

More information about the Operators mailing list