Sitecore logs out when I select a message in ECM

Whenever I select a message in ECM it redirects me to the login page of Sitecore with the following URL at the top

http://example.com/sitecore%20modules/shell/EmailCampaign/UI/Dialogs/MessageBody.aspx?message={79D6412B-824A-4349-8B94-9136D17C6E84}&lang=en&contact=Emailcampaign\exampleuser_at_example_dot_com

The following are the things I know about this issue:

Though this happens most of the times, Sometimes it will work for the same message and for the same preview user (For the contact mentioned in the URL above).
The sitecore user trying to access the message in ECM has all access rights for the message he is trying to access.
I have a test environment running on a different server where this works fine. But in the production environment it is not working.
I am running my site on Sitecore.NET 6.6.0 (rev. 121015) version.
When the sitecore redirects me to the login page with the above URL at the top. I cannot login using that page. I have to go to
```
http://example.com/sitecore/
```
in order to log back in.
The Item ID in the URL is correct and it points to the message that I am trying to view.

Solution

[Updated]

We resolved this issue by adding a custom preview handler in web.config like this

<previewManager defaultProvider="customPreview" enabled="true">
 <providers>
  <clear />
  <add name="default" type="Sitecore.Publishing.PreviewProvider, Sitecore.Kernel" />
  <add name="customPreview" type="PackageName.CustomPreview, PackageName" />
 </providers>
</previewManager>

Here is the code behind for that custompreview:

public class CustomPreview : Sitecore.Publishing.PreviewProvider
{
  public override void SetUserContext()
  {
    string shellUser = this.GetShellUser();
    if (!string.IsNullOrEmpty(shellUser))
        AuthenticationManager.SetActiveUser(shellUser);
    else
   {
        if(!Sitecore.Context.User.Name.Split('\\')[1].Equals("Anonymous"))
         AuthenticationManager.SetActiveUser(Sitecore.Context.User.Name);
   }
  }
}

[Old]

We resolved this issue. Strangely, this was related to badly configured load balancer. We still need to find what is going wrong in the load balancer but we don't face this issue when we remove one of the servers from the load balancer i.e., When the traffic goes only to one particular server, this issue doesn't occur. Since our test environment is deployed in only one server we never faced this issue there.