0

My ejabberd version is 19.08. With enabled mod_block_strangers error stanzas haven't been received.

Sending message to outside recipient (not local jabber) Example of out stanza with mod_block_strangers=on

<message to="615970@676373647364.com" id="aad7a">
<subject>test</subject>
<body>test</body>
<nick xmlns="http://jabber.org/protocol/nick">bot</nick>
</message>

XMPP isn't local. There is no error stanza. Should be, because this domain doesn't exist.

Example of out stanza with mod_block_strangers=off

<message type="chat" to="615970@676373647364.com" id="aadaa">
<body>test</body>
<active xmlns="http://jabber.org/protocol/chatstates"/>
<request xmlns="urn:xmpp:receipts"/>
<nick xmlns="http://jabber.org/protocol/nick">bot</nick>
</message>

<message from="615970@676373647364.com" type="error" xml:lang="ru" to="bot@*" id="aadaa">
<active xmlns="http://jabber.org/protocol/chatstates"/>
<request xmlns="urn:xmpp:receipts"/>
<nick xmlns="http://jabber.org/protocol/nick">bot</nick>
<error type="cancel" code="404">
<remote-server-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">DNS lookup failed: non-existing domain</text>
</error>
<body>test</body>
</message>

On the local xmpp's no such problem. Everything is okay. I think, it's because allow_local_users, that by default is 'true'. Example of stanza with local domain:

<message to="549725985745@localdomain" id="aadea">
<subject>test</subject>
<body>test</body>
<nick xmlns="http://jabber.org/protocol/nick">bot</nick>
</message>


<message from="549725985745@localdomain" type="error" xml:lang="ru" to="bot@localdomain/Psi+" id="aadea">
<nick xmlns="http://jabber.org/protocol/nick">bot</nick>
<error type="cancel" code="503">
<service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</error>
<body>test</body>
<subject>test</subject>
</message>

So if mod_block_strangers is enabled, we don't receive error stanza and error code from out server. Like, error msg is banning with message together.

Edit: updated to ejabberd 20.04. The same situation, no effect.

saxad
  • 7
  • 3

1 Answers1

0

On my server there is no normal error mapping.

I'm using ejabberd 20.04 with the default configuration.

When I try to join a room with name "room@aa", it complains with an error because the room name can't contain @, and that error stanza includes the XEP-0086 code:

<presence id='57:106609'
    from='room@aa@conference.localhost/user1'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <history maxchars='10000000000000'
    maxstanzas='200000000'/>
  </x>
  <show>away</show>
  <status>Busysss</status>
  <error code='400'
    type='modify'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <text xml:lang='en'
    xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Bad value of attribute &apos;to&apos; in tag &lt;presence/&gt; qualified by namespace &apos;jabber:client&apos;</text>
  </error>
</presence>
Badlop
  • 580
  • 3
  • 5
  • Thanks for feedback. My ejabberd version is 19.08. For example, my stanzas ` Hello world` If I send msg to unknow host, for example "di4nfu47.com", I receive the same answer – saxad May 25 '20 at 16:41
  • And if I send msg to unavailable jabber on my host, I receive correct error answer: ` Hello world Hello world` – saxad May 25 '20 at 16:49
  • Could you say, what is the problem? Why stanzas differ? And how can I receive all error, not only `service-unavailable` – saxad May 25 '20 at 16:49
  • I have found the problem. Problem is in mod_block_strangers. If I disable it, error stanzas sends well. What is the problem and why is it so? Because I send out stanzas, why mod_block_strangers causes such problem? – saxad May 25 '20 at 18:52
  • You must provide a way to reproduce the problem you have, otherwise nobody can help. How to configure ejabberd to reproduce the problem? Use a recent ejabberd version, like 20.04. What should a client send to provoke the problem? And what problematic response do you get? And you must show all this in a way that can be read! Putting comments here is a bad idea. If you want a clear and detailed response, you must make a clear and detailed question. So, go edit your original post with the minimal required details, if you expect somebody to spend time in looking at your problem. – Badlop May 25 '20 at 21:00
  • Sorry for mess. Serverfault format is not typical for me. I have edited the 1st msg. Added all info. Please, take a look. – saxad May 26 '20 at 18:45