Multiple people complain about accessing their sites or plugins in IE6.
Usually login problems in IE6 are caused by cookies not beeing written right.
 
Here are some fixes as listed on http://genotrance.wordpress.com/2006/11/23/session-cookies-rejected-by-internet-explorer/ :
P3P issue
As per this website, IE 6 had a new feature that would reject sessions in certain circumstances unless a specific header was sent clarifying the intentions of the web appliction. This seemed probable so I gave it a try.
I added the following to the top of my application so that every call would return this HTTP header:-
 
header('P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
 
It didn’t work so it was something else.
Session IDs transported by URL
This website claimed that the latest IE update increased the security levels and that applications had no choice but to hard code the session IDs in the URLs. This can be done by enabling the following option in php.ini:-
 
session.use_trans_sid = 1
 
Of course, this meant that every URL needed to have the session ID added to it. It didn’t feel like the right option since Microsoft wouldn’t break web applications so badly. Considering how many URLs each application has and how many applications are out there, it would be prohibitive to have to change them all to include a session ID.
Timezone issue
A third website suggested that IE was calculating session cookie timeouts incorrectly such that they seemed to expire in the past. As a result, these already expired cookies were rejected immediately. For example, if the server was in Hawaii and the client in Australia and the server requested a session timeout of one hour, the timeout would have already occurred as far as the client in Australia was concerned.
Firefox didn’t have this issue since it converts both the server as well as the client time to UTC and then calculates the timeout. As interesting as this was, this didn’t seem as the problem since both my laptop client as well as my server were in the same timezone.
Final Solution
The timezone issue did give me a hint to check the time on my client and server. My client is a Windows laptop which had the correct time and timezone thanks to being synchronized with the NTP protocol. My server on the other hand was out of sync.
The timezone was correct, but the UTC time was set to my local time instead. As a result, the server was actually six hours in the past as far as the client was concerned. A timeout of one hour would have expired in the past for an IE instance running on my client. No wonder IE was rejecting my sessions.
I ran ntpdate to fix my time and then reset my timezone using tzselect.
 
# ntpdate pool.ntp.org

# tzselect
 
I then refreshed IE which immediately started accepting the sessions. All aspects of my application started working correctly. So much for so little.
Moral of the story, use NTP to ensure that your machines have their time set correctly.