Description of problem:
When accessing a message on an Exchange server via evolution-connector, I
occasionally get a long piece of html garbage, which doesn't render, and deep
inside says that my Outlook Web Access session has timed out.  This can happen
with an old message (that is, I've read the message successfully before in
evolution) or a new one.  Once it has happened, the message has never correctly
rendered again.  If I log on to OWA directly, I can easily see the (correctly)
rendered message, so it's still there on the Exchange server.  If I forward the
message back to myself using OWA, it again renders correctly on both OWA and in
Evolution.  

I suspect that there's some sort of time-out happening, such that non-initial
password requests from OWA aren't answered quickly enough, and that the
occasional message just doesn't make it.  But then when evolution does
reauthenticate, the error page is already cached, and Evolution doesn't
re-acquire the message from the exchange server.  

Evolution is currently set to check for password expiration every 7 minutes;
I've reduced that to 5, and I'll see if that helps.  

I've attached a saved version of one such bad message.  You'll note that it has
the headers of an email message.

Version-Release number of selected component (if applicable):


How reproducible:

It happens fairly rarely, less than 1% of messages.  I can't control the
occurance, and have not yet found anything that influences the frequency.

Steps to Reproduce:
1.  Use evolution/evolution-connector for a long time.
2.  
3.
  
Actual results:

Message displayed with correct headers, but funky non-rendering html body
indicating OWA timeout.  Message never is restored. 

Expected results:

I would expect the message to be correctly rendered, but if not, I'd expect it 
to be possible to "redownload" the message.

Additional info:

I know this one's going to be a bear to track down.  Intermittent things are
just a pain.  But I wanted to let you know about it.  I suspect that shorting
the password expiration check may reduce the frequency of the problem to
effectively zero, which seems a reasonable solution.