[Standards] MUC Spam and MUC invites

Adam Nemeth aadaam at gmail.com
Wed Sep 5 15:21:18 UTC 2007

Hi all,

Most of you may probably now that conference.jabber.org's rooms had
spam-problems recently - https://stpeter.im/?p=2041 .

You may also know that Google does not allow MUC invites because it
does not come from somebody on your contact list, but from the room.

I'd like to say that - by my own, web-based experiences -
spam-technoligies spread fast. It took two weeks for a spam-program to
raid all of our forums done with a rarely used - although open-source
- cms, even when it had additional javascript security. They were on
different IP addresses, different domains, different versions.

Since the public servers' list is publicly available, and it's
probably available as well in a machine-readeable format (XML), I
believe, that a lot of us in this mlist - including me - could extend
the spambots' code which raided on jabber.org to go through all public
jabber servers in less than an hour, not to mention that a lot of us
could write such bot from scratch less than a day. (I hope noone is
intended to do of course).

So, what I'd like to ask is
- Some informational XEPs on preventing MUC-abuse
- Fast adoption of those from major public jabber conference servers
(jabber.org, jabber.ru, jaim.at.......), or possibly all public
servers with muc-support
- Allowing direct invitations for MUC, so they could be blocked / or
ask google to examine the invitations' body and reject by that.
- Adoption on client side (at least for receiving)
- Make it an option for user to prevent abuse on client interfaces
(and/or even libraries)

A direct invitation would probably look like as follows (modified
example 46 and 47 from XEP-0045):

    from='crone1 at shakespeare.lit/desktop'
    to='hecate at shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='crone1 at shakespeare.lit/desktop'
to='darkcave at macbeth.shakespeare.lit'>
        Hey Hecate, this is the place for all good witches!

The from attribute in invite element is redundant, it's just for
easier migration/backwards compatibility, it could be removed of

There's already a place for 'to' element in the xsd, it's optional now:

  <xs:element name='invite'>
        <xs:element ref='reason' minOccurs='0'/>
      <xs:attribute name='from' type='xs:string' use='optional'/>
      <xs:attribute name='to' type='xs:string' use='optional'/>

Maybe some of this could be changed to 'required'.

Aadaam <aadaam at gmail.com>

More information about the Standards mailing list