Hello, I announced today a project I had in mind since last July, which aims at helping XMPP server operators fight spam in a *proper* way.
The project is called Providence, and aims at being a generic daemon that can be plugged to any XMPP server via a server module. Works similarly to SpamAssassin for email. Project on GitHub: https://github.com/valeriansaliou/providence <https://github.com/valeriansaliou/providence> Post describing & explaining the project: https://journal.valeriansaliou.name/announcing-providence-a-spam-filter-for-xmpp/ <https://journal.valeriansaliou.name/announcing-providence-a-spam-filter-for-xmpp/> Providence will implement a set of filters that are known to work well for email, and I suspect will also work decently well for XMPP (see Features category on GitHub in the README). As I am very busy at the moment on other projects, I postponed the release of a first working testing version of Providence to the end of the first semester of 2017. If you have any idea to suggest / or you want to discuss about an idea I proposed in the project/article, I’d be more than happy to discuss this there! -- Valerian Saliou > On Nov 19, 2016, at 10:40 PM, Dave Cridland <[email protected]> wrote: > > On 19 November 2016 at 13:27, Krzysztof Grochocki <[email protected]> > wrote: >> Hello. >> >> Over the past year I received spam message only in russian language or in >> russian and english language together. I think we can block such messages >> like it is in one of polish IM - just block incoming/outgoing messages where >> is Cyrillic characters in text. At this time it's only the one way to stop >> spam. Maybe someone can write such functionality as module for ejabberd and >> prosody? > > It works; it's even useful for some deployments. > > https://github.com/dwd/Metre/blob/master/src/filters/unicode.cc > > Setting that just to block cyrillic blocks is pretty good for me, actually. > > But it's obviously not a universal solution. > > SPIM is hard because they're very short messages and the intention is > to forward along to the client (more or less) instantly. So unlike > email, where we can delay to see if we get other, similar messages - > and note that even this is only useful for a large server - or delay > while we do some enhanced lookups (RBL checks on URLs, for instance) > delay is going to block a considerable amount of traffic due to the > in-order rule, which in turn introduces a potential DoS. > > For personal servers - and we really want to encourage these - there's > very little we can do, and the risk of deploying a quick fix like the > above is that wide deployment would simply progress an arms race. > > Dave.
smime.p7s
Description: S/MIME cryptographic signature
