Blocking/Privacy list not working as expected with offlinestorage and muliple clients


From forum post

I know that XEP-191 was added with 1
So i added a several jids to test (bare and fulljids) but the stanzas from my blocked testusers are still routed to the client…
The JIDs were added successfully to the Privacy Lists… I can see them in the admin console…

XEP 191 @ 3.3 says the following:

Once the user has blocked communications with a JID, the user’s server MUST NOT deliver any XML stanzas from the JID to the user. The block remains in force until the user subsequently unblocks commmunications with the JID (i.e., the duration of the block is potentially unlimited and applies across sessions).

EDIT: It seems the message are stored in OfflineMessageStorage so that they are delivered if the receiver comes online… Wouldnt it be better to dont save them to offlinestorage if the user is blocked?

EDIT2: It also seems that the privacy list does take a while until it will block the traffic. Maybe it is only refreshed after user reconnects… because if i am online with two clients on one account and i block another user the message are still routed by openfire…

Edit 3: i also added a 4th Client Gajim with a running XML Console… I noticed that the messages are carbons which arrive at gajim… so maybe the MessageCarbonHandler should check for PrivacyList too

My Setup:
Openfire 4.6
Conversations at 5222
and two Instances of JSXC on which i am implementing XEP 191 on Bosh Connection 7443
I can write from one JSXC (blocked user) to the other JSXC (one of the two clients that block the sender)




January 19, 2021, 8:56 PM

User B is blocked by User A.

Bug 1:

B sends a message to A:

Instead of switching the to and from attribute the two attributes are equal which is wrong i guess

Bug 2:

from attribute is missing on error messages if B is sending messages to A.

January 16, 2021, 11:15 PM

Ok i tested around with theese cases:

User A (blocked) , User B (receiver)

  1. A is online, User B is online with one client, A sends message:
    result: message blocked

  2. A is online, User B is online with one client, B comes online with a second client
    result: message not blocked
    B receives:


3. A is online, User B is offline, A sends message, User B comes online
result: message blocked / not received

4. A is online, User B is offline, A sends message, User B comes online (Case 3), User B comes online with second client
result: message not blocked, same result as case 2

5. A is online, User B is online with more than one client, A sends message
result: message blocked / not received


It seems messages come from MAM now

January 16, 2021, 10:27 PM

Thanks i will test this later…

Guus der Kinderen
January 16, 2021, 9:33 PM

Thanks for reporting this, Ramon, and thanks for the detailed descriptions. Those are helpful.

I have implemented, but not tested, fixes for the carbons and offline message storage in this PR: Would you mind testing them?

As for the error message: Openfire implements XEP-0016 Privacy Lists, and simply maps XEP-0191 on top of that. This is why you’re getting errors that do not correspond with XEP-0191, but with XEP-0016: I’m not sure if this is easily fixable. Maybe we will need to track which XEP the user is using, and base the type of error to be generated on that. I’m kind of reluctant though, as that will get messy fast.

January 16, 2021, 6:45 PM

Furthermore i noticed that Openfire does not follow the standard XEP 191 when sending the error message…
The packet should look like this:

but it does like this (when sending from user to blocked user)

so the tag

is missing

and when sending from blocked user to user which blocked the sender:

so the tags


are missing

i think <blocked xmlns='urn:xmpp:blocking:errors'/> is the most important here…

Your pinned fields
Click on the next to a field label to start pinning.


Guus der Kinderen