It depends of the workflow you use, and essentially the relations between developers and customers.
In Extreme Programming, it belongs to the customer representative to decide what to do with the ticket. She may consider that it's high priority and you should work on it, or low priority, or should be removed. Whether the bug is reproducible is a different story and should become a primary concern if and when the customer representative considers that the team should work on the issue.
If, on the other hand, in your workflow, it belongs to the developers or the project manager to consider the priority of a bug report, then, well, you have a choice. With no interest from the customer to work any longer (or at all; it often happens for projects where any customer can submit a bug report, especially when reports are submitted mostly automatically), you can decide either:
To continue inspecting the bug, trying to reproduce and eventually solve the issue.
To consider that the ROI of fixing this bug is probably below zero. This may happen on frequent basis, such as when the bug concerns an outdated version of the product.
In this case, close the issue as “not reproducible”. Don't label it. Close it: you don't need to pollute your bug tracking system by keeping such bugs opened. Make sure your bug tracking system still keeps those bug reports accessible, including to your customers: such bug may be reopened by another customer who may be able to reproduce the issue.