When a client loses network connection Openfire may not become aware of this, after all TCP was designed to survive physical connection outtakes, and do not store incoming messages in the Offline storage. So messages in this situation are sent into void and are lost.
Set a system setting in Openfire (Server Settings > Client Connections > Disconnect clients after they have been idle for) to 30 seconds or any other reasonably low value to make this issue appear as rarely as possible. This means that Openfire will disconnect clients that have been idle for 30 seconds and are not responding to ping requests. One can set it even lower, but it can have a side effect: clients disconnecting and reconnecting often.
This is only a workaround and there is still a chance to lose a message in this 30 or so seconds gap.
Stream Management as defined in XEP-0198: Stream Management is meant to solve message loss because of network problems. Both a client and a server has to support this.
Openfire has a partial support of this since 4.0.0 version: OF-446 Implement XEP-0198: Stream Management
Note: Openfire currently has a bug in the implementation, which makes it nearly impossible to properly use Stream Management and it is advised to turn it off for now. It should be fixed in the upcoming 4.3.0 version. OF-1497 Server appears to drop client session (sends ‘unavailable’)
Both endpoints of a XMPP stream must support Stream Management, so a client has to support this too. Smack library (which Spark and some other clients are based on) has added support for this in 4.1.0 version: SMACK-333 Implement XEP-0198: Stream Management
There is a ticket to add this functionality to Spark: SPARK-1785 Add support for XEP-0198 Stream Management
Message Delivery Receipts:
Another approach would be to implement XEP-0184: Message Delivery Receipts in a client. This way a client would get a notification that a message hasn’t been delivered (or vice versa a notification that a message has been delivered). This is strictly a client side feature, server doesn’t have to support this.
Smack already supports this (since 3.3.0 version): SMACK-331 Add support for XEP-0184: Message Delivery Receipts
Spark is using the latest stable Smack version of 4.1 branch, but there is no GUI in Spark for this yet: SPARK-1238 Add support for XEP-0184: Message Delivery Receipts
Most modern XMPP clients support Message Delivery Receipts. E.g. Gajim client shows a red cross icon beside a message which hasn’t been delivered.
Similar to delivery receipts is the newer XEP-0333: Chat Markers which implements special markers for messages (e.g. read, displayed, acknowledged). This XEP is still in the proposal state. But some clients and libraries already support it.
Smack added support for it in the 4.2 branch SMACK-736 Add support for Chat Markers (XEP-0333)
Android client Conversations is known to support it also. Spark has an open ticket to add such functionality SPARK-1834 Add support for XEP-0333 Chat Markers