[Operators] Spam Problem And Its Simple Solution

Marco Cirillo maranda at lightwitch.org
Sat Nov 19 19:15:55 UTC 2016


I can't believe what I'm reading...
So we went from the usual "it can be bypassed" excuse to not employ any 
SPIM mitigation to "let's leave IBR the way it is it's the client which 
should deal with it".

I'm simply speechless at this rate.

Il 19/11/2016 13:19, A ha scritto:
> Hey everyone.
>
> The spam problem persists and it gets worse and worse each consecutive 
> day, but seems like nobody actually can or wants to do anything. All 
> the anti-spam measures discussed here in this list are a mere blocking 
> of spam JIDs or even whole domains.
>
> But this will not mitigate the spam problem and moreover this is not a 
> solution.
>
> XMPP is blatantly famous for its truly decentralized federation and a 
> high possibility of automation. This is why it is number one choice 
> for security-concerned internet users and also criminals of all sorts. 
> The situation is very similar to that of Bitcoin.
>
> But criminals cannot disrupt Bitcoin, because its ecosystem doesn't 
> really have human-managed weak points. It does have miner points, but 
> miner operators rarely do anything. Typically miner-node just runs and 
> mines and operator just keeps an eye on it to check if it's operating 
> well and with the lastest software. There is an automated 
> decentralized Blockchain which automatically sorts out all problems 
> with the network. XMPP doesn't have a blockchain. XMPP is 
> human-maintained.This is a weak point from the infrastructure point of 
> view.
>
> XMPP's decentralization and lack of any sort of authority enabled 
> spamers to easily facilitate the system to conduct huge spam 
> campaigns. I have my JID posted on Internet and get tens of spam 
> messages every day.
>
> Due to a decentralized nature of XMPP, this problem can't be solved by 
> operators of some nodes. Even if all the operators unite (which will 
> not happen anytime) and start cooperate, the problem will persist. 
> When you block 10 JIDs, spamer pushes one button and automatically 
> creates 1000 new JIDs on dozens of nodes (your included). When you 
> block the whole node, more of others get used. This is essentially war 
> with a multi-headed hydra, when 3 new heads are instantly grown up 
> when you cut off just one.
>
> The solution to disable an in-band registration and/or supervise every 
> registration are not solutions at all. XMPP enables people to free 
> communicate with easy registration process, and removing the "easy" 
> part from this equation renders the whole XMPP system questionable. 
> Why should users take additional complicated steps when they still can 
> use Facebook Messenger or Hangouts?
>
> Some operators block particular IPs which is a bad practice as well, 
> and in the case of my service it will not work, since it has enabled 
> .onion-address.
>
> But the solution to the problem is actually very, very easy. We just 
> need to take experience from the past.
>
> In the early days of internet messaging in Russia ICQ messenger was 
> prevalent. This was a service with a single authority, but for some 
> reason it, a single Israeli company at the moment, was not able or 
> simply didn't want to do anything to with huge amounts of spam which 
> fell upon the network. So the prerequisites are the same as in the 
> XMPP today: there is a persistent spam and there is a lack of 
> possibility or simple neglect from operators to do anything with the 
> problem.
>
> How do this problem was solved back in 2000s? Very easy. Popular 
> clients just incorporated simple anti-spam measures to perform 
> human-testing for any new senders. Client just asked every new sender 
> to answer simple (customizable) question, such as "What is the planet 
> name we are living on?" and if sender managed to answer, the client 
> allowed sender to actually communicate with the recipient. This is 
> just that easy.
>
> Looking at clients I use for XMPP messaging: Gajim, Pidgin, Adiumand 
> Conversations- none of them have a decent easily accessible anti-spam 
> solution. Gajim does have "Anti Spam" plugin, but it doesn't have the 
> "question/answer"feature. The Pidgin doesn't have any anti-spam 
> plugins in its plugins list, and although there are some plugins on 
> the Internet, most people will not search plugins themselves (not to 
> mention most people doesn't know or want to knowhow to install 
> third-party plugins to Pidgin). Conversations doesn't have plugin 
> system and doesn't have native anti-spam measures. I emailed Daniel 
> Gultsch (author and maintainer of Conversations) once if there is a 
> possibility to add anti-spam feature in some future release,but for 
> some reason he didn't answer me.
>
> Authors of clients and plugins should be concerned about the issue. 
> They shouldbemotivatedto implement simple counter-measures.This is not 
> a difficult task, someone just need to take his time and do this. 
> Maybe someone from this list have relevant skills and can implement 
> required plugins and someone else can persuade client authors to 
> include this plugin to the default list, which comes with the app.
>
> To combat automated threat we just need to answer accordingly, with an 
> automated defense solution.
>
> XMPP is an open and mostly unmaintained/unmonitored/uncensored network 
> and it should to stay this. Users should be able to protect themselves 
> without any help from node operators.
>
> Take care, A.
>



More information about the Operators mailing list