As you have already looked into the problem, could you please provide more details about it. Which addresses affect the processing (Stanza/Packet/From/To). Ideally use case how to reproduce the problem or point me to the DefaultPacketHandler part of the code which incorrectly handles such packets.

It was caused by the following change:

https://projects.tigase.org/projects/tigase-server/repository/revisions/43ffa897dd3668646ca3a02a38b18d64ed709a96

and most exactly this new code:

if (resource == null) {

	// In default packet handler we deliver packets to a specific resource only
	result = Authorization.FEATURE_NOT_IMPLEMENTED.getResponseMessage(packet,
			"The feature is not supported yet.", true);
	result.setPacketFrom(null);
	result.setPacketTo(null);
} 

and example stanza:

<ack type="subscribe" xmlns="myapp:event:presence-ack" jid="tigase1@atlantiscity" to="admin@atlantiscity"/>

Basically stanzas outside normative XMPP, without resource won't be forwarded to any connection but simply dropped.

It remains to be discussed what would be best option to handle such scenarios.

I think current implementation does the right thing. If there is not resource then Tigase should not do anything about unknown stanza and simply return an error. As far as I understand RFC XMPP server should reject any unknown stanza whether there is a resource or not, so Tigase now is even more forgiving.

It seems that current implementation does make most sense as it kind of protects people from malicious stanzas sent by strangers. Those who have your resource are most likely your friends from a roster.