Helllooo?
What's this discussion all about? RoundCube has a session timeout for security reasons, which can be turned off by configuration. Please, no more discussion about advantages and disadvantages of session timeouts or about intelligent and stupid users!
Fact is, RoundCube has an ugly bug which needs to be fixed. I also spent some time to find out how this can happen (even if I can't reproduce any session failures here).
As far as I can see, the session timeout (the time that can be configured) isn't the reason for this RoundCube bug. Even if you set the session timeout to 10 minutes, it should not really time out because the client sends a keep alive signal every minute.
In 0.1-beta2 I removed the _auth hash from every URL and introduced a second cookie which changes it's value every five minutes. The problem of the session authorization failures could be related to this. This second cookie is here to prevent from stealing somebody's session by reading the session cookie.
A session failure could occur if a request (like draft saving [btw. yes, we already have an automatic draft saving mechanism!]) takes a lot of time. In that case, the cookie could be switched to a new value but the HTTP header has not been sent to the client yet. If the keep-alive request is sent in the meantime, it arrives with the "old" cookie value which will cause RoundCube to deny the request and send a redirect to the login screen.
With revision 338 I added some fall back for checking this changing session cookie. There's also a log file (log/timeouts) that will be filled with $_REQUEST and $_SESSION values if the session authorization (not session timeout) fails.
Please get the latest trunk and test it.
Thomas