jabber.hot-chilli.netWe just blocked Nimbuzz traffic via our iptables firewall. At the moment this is just a test, but maybe we will block Nimbuzz for good.
The system has way too much CPU and memory usage and is not running stable. We have to do something about it. If it means that we have to block out Nimbuzz as there is no other way, then it is has to be the solution.
At the moment we don’t have any idea why. As I am in Italy right now I will investigate this after my return home in the middle of the week. Please stay tuned.
Is anybody aware of any current exploits for ejabberd?
We offer you quick information about short notice downtimes and maintenance work, but also about updates of our website via Twitter. Just follow us.
Do you want to contribute with content or content translation?
Unfortunally we don’t have as much time as we wish to have and also we don’t speak all the languages in which we want to offer this website. We are happy about any help you can offer us. ;-)
One of the main reasons we were really looking forward for ejabberd 2.1.6 is the support of captcha for mod_register. This module handles in-band registration, which means the interface where users can register through their client. This interface is also abused by spammers. We hope that the use of captchas will prevent most spam registrations.
If you client does not support captcha you well see a url where you can see the captcha in your browser window.
Finally the Debian package for ejabberd 2.1.6 is available. Therefore we will perform an upgrade to ejabberd 2.1.6 in the next minutes. There will be a short service outage.
We noticed that buddies in Jabber roster are now renamed into the original names from the legacy networks, e.g. ICQ or Facebook.
This affects just local transport users as remote roster only works on the same server.
Sorry about that… But now the rosters are synced and renaming the contacts will also rename the contacts in the legacy network roster. If renaming in the legacy network is not supported the databases of Jabber and the transport service are synced anyway.
We experienced problems with ICQ transport the last days. According to the developers of Spectrum this is a “glib poll” issue. epoll unfortunally does not work with glib (yet).
Therefore Spectrum ICQ transport now uses libev3 and epoll.
It looks good at the moment, I hope it stays that way. We will see what happens during the next days as our server is the only server which runs this configuration. Not even the Spectrum developers were able to test it, yet. ;-)