We have a mobile website, which is built as a single page application. We have tried to keep the back button alive by using anchors for different screens (it still feels pretty much like a paged website). Users can for example see a list of messages, go to one message, then go on to see the profile of the user. On the message and profile page instead of a navigation menu theres is only a link/button to "go back" (left arrow), which uses javascript:history.back() in the hope of not breaking the back button too badly.
Now we had the problem that we wanted to link directly (e.g. from mails) to a profile or a message. In this case the back button/link is meaningless, because there is no prior point within the site to go back to. But since there is no always-accessible menu on these pages, the user has nowhere to go.
Now, the question arose how to handle this. Is it better to fake a back location via javascript trickery (injecting a logical target for the back link), or rather do away with this back linking button in favor of a global navigation menu that can be accessed on every page and leave back navigation to the browser back button?
My instinct would be to leave back to the browser controls and have a consistent navigation menu on all pages. I would think having only the back button makes sense only in very select situations where a page doesn't make much sense on its own (like a page in a multi-step wizard). Our UX person argues that with the back linking button it is easier to go back to the list and read the next message (a navigation pattern that is found like this in the iPhone app for example). Having both hits against space constraints.
Are there any best practices I could read up on or point to for this kind of situation?