You can take it as a sign of success of a network when it becomes worthwhile for spammers to set up camp. If you’re an active user of XMPP, there is a chance you’ve been unfortunate enough to receive spam in recent weeks.
Spam has always been an occasional issue on the network, as with any network, website or internet service. However a few years ago spammers really started to take things more seriously on XMPP. With the advent of paid XMPP spamming services such as XSender in 2017, spam has become a recurrent issue for many people.
We knew this day would come. The first XMPP anti-spam XEP (XEP-0159) was published back in 2006, long before any serious spam activity was seen on the network. Subsequent specifications addressed different aspects of the issue, such as blocking and reporting and reputation tracking. Adoption of these XEPs was slow to non-existent, probably because developers did not prioritize implementing defences against a problem that was quite uncommon at the time.
However the problem is now so common that most of us are in a position to contribute in some way to the spam-fighting effort.
Implement XEP-0377! This gives users a way to block and report spam JIDs. While simply blocking individual JIDs isn’t going to have a large impact (spammers register hundreds of JIDs at a time), informing the server of spam allows for further action to be taken (e.g. identifying and potentially blocking servers that are relaying spam).
Also consider reducing the notification priority of messages and subscription requests received from non-contacts.
First and foremost, ensure your server isn’t contributing to the spam problem by acting as a relay. Know
whether you have registration enabled on your server. In Prosody this is the
If it is set to
false or not present, then you are good!
If you run a public server and want to continue allowing people to register on your server, please keep an eye out for suspicious registrations using e.g. mod_watchregistrations, and consider some additional layers to prevent your server being used as a spam relay, such as restricting accounts from open proxies. We also have a lot of general advice for Prosody operators running a public server.
If you’re not keen on running a public server, but enjoy the convenience of in-band registration, consider enabling the new invite-based registration we recently announced!
Ok, so you’re satisfied that spammers aren’t using your server to send spam. But what about incoming spam?
Luckily there are a number of resources readily available for server operators.
The JabberSPAM project publishes resources for server operators combatting spam. As well as a curated list of spam-relaying servers, they host a manifesto for server operators and documentation of anti-spam server modules for a range of server software, including Prosody.
Of particular interest to Prosody administrators should be the documentation for using the extremely powerful mod_firewall module to identify and block spam. A good start would be using the JabberSPAM blocklist, and possibly also adding custom anti-spam rulesets if you need.
If your XMPP client supports spam reporting, please report spam when you receive it! Also do contact your server operator to ask what they are doing about the problem. Point them to this blog post and the associated resources so they know what help is available.
Tackling spam is a collaborative and ongoing effort. Although it is unlikely we will ever eliminate it completely, especially difficult on a decentralized network, we have lots of existing tools and many more continue to be developed and adapted, just as the spammers continue to develop and adapt their techniques.
As always feel free to discuss this post in the XSF operators chat (linked above) or any of the Prosody community discussion venues.