I have not found a way around the situation you describe in ConnectR - refiling a message sends it through the source system again, which means it will be processed by each of the target systems mapped to the source system. I have seen other middleware applications support this behavior, but not ConnectR. For your specific situation with LIVE and DEV, there are a couple workaround solutions.
1. You could install another instance of ConnectR on the DEV system and send all HL7 messages from your current LIVE source systems to DEV source systems. Galen configured our DEV environment in this manner a couple years ago and it has worked well. We have target systems in LIVE with pass-thru mappings that send all source messages to specific ports on the DEV system. The DEV instance of ConnectR has corresponding source systems listening on the ports and maps them to target systems that are connected to the DEV Works database. This way, if you needed to refile any messages for DEV only, you could do so in the DEV source system and not affect the LIVE systems.
2. If you don't have a DEV environment for another instance of ConnectR, you could create another source system (called DEV Source) in your LIVE ConnectR, "pass thru" all messages from your current LIVE source to the DEV Source via TCP/IP, and then map these to your DEV Target. This is similar to the above setup in that if you need to refile any message only for DEV, you could so within the DEV Source system and not impact the LIVE systems.
In general, the workaround is to create a new source system that receives copies of messages from another source system. In either of these setups, you can refile messages just in DEV by doing so within the "secondary" system, but if you refile any messages in LIVE they will trickle down to the secondary system(s).
I hope that helps.