I checked code and found a way in which this packet could be delivered to sess-man@. This could happen if @<db:verify type="error"/> packet was sent to us on authenticated connection with XMLNS not set and in parent <stream:stream/> element there was no db:xmlns="jabber:server:dialback" attribute. As in other either packet would be rejected (due to not authorized connection) or XML parser would change it to <verify xmlns="jabber:server:dialback" type="error"/> and this packet would be processed by S2S.

This case is very small and only solution I see at this point would be to filter every packet by checking it's name - however I do not think this is needed as packet was properly rejected.

I tried to check which server implementation was used and triggered this issue, however at this point there is no XMPP server for domain wjabber.net so I cannot check it and find cause of this.

Ok, thanks for looking into this. I wonder if this may happen when a server tries to reuse the same s2s connections for multiple domains and tries to authorize another domain on a connection which is already used for some domain.

In any case, if the packet was correctly handled in the server, then we can leave it as it is.

It could but only if last stream open Tigase received (inner stream open, ie. after starttls@) @<stream:stream> was without db:xmlns attribute - in that case this <db:verify> packet should be sent with xmlns set - while here it was not and was not handled by dialback.

From what I see, this was issue with bad s2s stream (issue in implementation of s2s in remote server). However there is no impact on our current implementation - except for log entry, so I think we can leave it as it is.