Our session timeout is currently set to 0 days, so I'm guessing that's effectively no timeout. Despite this, we still have users getting timeouts that they do not discover until they compose (sometimes a long) email.

In one user's case, as best as I can tell this was the series of events:

They login:

2011-02-16 00:13:15,080 INFO [btpool0-53472://localhost/service/soap/BatchRequest] [name=xxx@xx.xxxxx.xxx;mid=372;oip=000.000.000.000; ua=zclient/6.0.7_GA_2473.RHEL5_64;] soap -
BatchRequest
(other lines omitted)

logs showing usual day web interface traffic.. followed by a dormant overnight spam filled with NoOp's.

At some point the next morning the user goes back to his tab, clicks 'new message', composes a message, clicks send and it boots him to the login screen, message lost. We see in the logs:

2011-02-17 15:52:00,521 INFO [btpool0-55562://xxxx.xx.xxxx.xxx/service/soap/AuthRequest] [name=xxx@xx.xxxxx.xxx;ip=000.000.000.000;ua=Zimbra WebClient - FF3.0 (Win)/6.0.7_GA_2473.RHEL5_64;] SoapEngine - handler exception: authentication failed for xxx@xx.xxxxx.xxx, empty password

This understandably upsets people, and certainly doesn't look like good UI design. I get the idea Zimbra is doing its best to be an Outlook replacement.. but as poor as you might think outlook is, it doesn't reliably poof and disappear once you've finished composing an email, like the Zimbra web interface will.

Is there any workaround for this I have missed on google and the forums? If not, the best answer sounds like just setting an 8 hour login timeout and tell them they have to deal with it.