Don't attempt creation of the dump file while checking the validity of
the "spam_dump_file" option, as the @HOST@ keyword can't be expanded at
this point.
Thanks to Nico Wellpott for reporting this issue.
If the API commands are called with 'global' instead of a host name,
only run the command for those virtual hosts that actually have the
module loaded.
The mod_default_rooms module doesn't just work in conjunction with
mod_register, as bookmarks are also auto-added for users registered via,
for example, the "ejabberdctl register" command. Update the code and
the documentation accordingly.
Thanks to Licaon_Kter for noting this.
Also check whether the message body contains a listed JID (usually
mentioned as a contact address), rather than just using the JID list to
check the 'from' address of incoming stanzas.
Don't crash if the module isn't loaded for the 'to' domain. This would
otherwise happen for stanzas sent to subdomains (e.g., MUC messages).
Thanks to Nico Wellpott for reporting the bug and testing the fix.
Add a module that allows for filtering spam messages and subscription
requests based on lists of known spammer JIDs and/or URLs mentioned in
spam messages.
Thanks to Georg Lukas for his suggestions.
It makes sense that vCard in XMPP roughly maps to WHOIS in IRC,
but there is no code that actually handles receiving WHOISes properly:
they just get passed through as plain messages coming from user!ircserver@irc.xmppserver.tld.
I suppose sometimes you want to manually be able to run a WHOIS and see the results,
so I don't want them banned entirely, but I don't want them on each run.
Sending spurious WHOISes pisses off Xabber, which overenthusiastically sends "get vCard"
IQ stanzas on every single presence change (even "unavailable"); this has the horrible
side effect of spawning a huge number of private chats with users I have never talked to,
and buzzing my phone uncontrollably for a good minute, whenever I join a channel with more
than 50 people in it, and the same every time someone's connection drops.
Disabling this scratches an itch for me and patches over what is arguably Xabber's problem,
but in fact, this code was already half-disabled: *even though it sends IRC commands* it
returns ?ERR_FEATURE_NOT_IMPLEMENTED. Was this an oversight?
Conversations doesn't set Priority, in that case assume it's zero:
If no priority is provided, the processing server or client MUST
consider the priority to be zero ("0").
https://tools.ietf.org/html/rfc6121#section-4.7.2.3
