[ejabberd] MUC handling of non-groupchat messages

Badlop badlop at gmail.com
Wed Jan 9 01:37:06 MSK 2008

2008/1/8, Peter Saint-Andre <stpeter at stpeter.im>:
> I have a report that ejabberd 1.1.3 or 1.1.4 will kick a MUC room
> occupant if the user sends a message to another occupant and the message
> is of type "error". For example consider the following exchange (JIDs
> changed slightly)...
> <message type="groupchat"
>           from="psi at conference.psi-im.org/foo"
>           to="psi at conference.psi-im.org/bar"
>           id="abcda">
>    <body>This message is encrypted.</body>
>    <x xmlns='jabber:x:encrypted'>
>      big-encrypted-blob-here
>    </x>
> </message>

Is this stanza a private message sent by the client?

In that case, Type should be 'chat', and From should be the user's
JID, not the room participant JID, right? Better something like:

<message type="chat"
          from="senderuser at example.org/Res"
          to="psi at conference.psi-im.org/bar"
   <body>This message is encrypted.</body>
   <x xmlns='jabber:x:encrypted'>

> <message type="error"
>           from="psi at conference.psi-im.org/bar"
>           to="psi at conference.psi-im.org/foo"
>           id="abcda">
>    <body>
>      [ERROR: This message is encrypted, and you are unable
>      to decrypt it.]
>    </body>
>    <error type="modify" code="406" >
>      <not-acceptable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
>      <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">
>        Unable to decrypt
>      </text>
>    </error>
> </message>
> At this point, ejabberd will kick user "bar" from the room. That seems
> unfriendly, and potentially even a DoS. I think it would be better for
> ejabberd to deliver the message or, if that is thought to be a problem,
> at least ignore the stanza.

Looking at mod_muc_room.erl SVN, ejabberd kicks a participant that
sends a stanza with type=error in three situations:
  Line 294: a message sent to the chatroom JID
  Line 473: a message sent to a participant's JID
  Line 895: a presence update
Alexey implemented those checks [1] to kick dead connections, e.g. if
a participant's server crashed, or network failure occurred.

The check that annoys you is the one in line 473. Once removed [2],
ejabberd no longer kicks the participant, instead it delivers the
message to the other participant. Alexey accepts to remove it, and
hopefully the checks in lines 294 and 895 will be enough to kick dead

I'm checking with Textshell if my proposed patch is enough to fix this problem.

BTW, this bug is tracked here:
MUC kicks a participant if sends a private message with type=error

[1] https://forge.process-one.net/changelog/ejabberd?cs=108

[2] Patch for SVN, probably works with 1.1.x too:

--- a/src/mod_muc/mod_muc_room.erl
+++ b/src/mod_muc/mod_muc_room.erl
@@ -470,21 +470,6 @@ normal_state({route, From, ToNick,
     Type = xml:get_attr_s("type", Attrs),
     Lang = xml:get_attr_s("xml:lang", Attrs),
     case Type of
-       "error" ->
-           case is_user_online(From, StateData) of
-               true ->
-                   NewState =
-                       add_user_presence_un(
-                         From,
-                         {xmlelement, "presence",
-                          [{"type", "unavailable"}], []},
-                         StateData),
-                   send_new_presence(From, NewState),
-                   {next_state, normal_state,
-                    remove_online_user(From, NewState)};
-               _ ->
-                   {next_state, normal_state, StateData}
-           end;
        _ ->
            case (StateData#state.config)#config.allow_private_messages
                andalso is_user_online(From, StateData) of

More information about the ejabberd mailing list