Spam control #1123
Spam control #1123
Conversation
…a presence and has not been processed at all
… a proper state to keep going)
|
s/spam/spim/ ? |
|
s/spam/overuse/ ? |
|
As the name of the sample module, load or overload would be fine. But names of the hooks should be more generic - you can implement any type of spam protection, content-based, blacklisting senders, whatever, or even do useful stuff not related to spam at all. |
|
"abuse" is even more generic than "spam". :) |
|
On the other hand, one could use the same mechanism for rewarding users for clever things they say (if somebody invents an algorithm to tell clever things from stupid) |
| @@ -249,7 +250,12 @@ handle_stream_start({xmlstreamstart, _Name, Attrs}, #state{} = S0) -> | |||
| {?NS_STREAM, true} -> | |||
| change_shaper(S, jid:make(<<>>, Server, <<>>)), | |||
| Version = xml:get_attr_s(<<"version">>, Attrs), | |||
| stream_start_by_protocol_version(Version, S); | |||
| SpamCtlState = ejabberd_hooks:run_fold(spamctl_initialise, | |||
There was a problem hiding this comment.
These spamctl_* set of hooks are quite powerful. How about passing whole c2s state as an arg to the initialise hook handler so the implementation may choose what to do with it? Other solution would be passing the state to all the hooks. I can imagine that some clever logic (rewording or stopping the user) may need some of the fields which are in c2s state.
This PR adds a spam control feature.
There are minor changes to ejabberd_c2s, which provide a way to write and attach a custom
spam control plugin, which would process all messages and react if necessary. Includes a simple
throughput-based plugin.