Re: [Evolution] missing messages [solved]

[Ross Boylan <ross biostat ucsf edu>]

On Sun, 2014-04-13 at 19:35 -0400, Paul Smith wrote:
> On Sun, 2014-04-13 at 14:29 -0400, Adam Tauno Williams wrote:
> > On Sun, 2014-04-13 at 11:20 +0100, Patrick O'Callaghan wrote:
> > > On Sat, 2014-04-12 at 20:27 -0700, Ross Boylan wrote:
> > > > Is using IMAP+ advisable in 3.4.4?  I have some large folders, and the
> > > > amount of time spent redownloading the message summaries (I
> > > > suppose--it's downloading something) at each poll, and hanging up the
> > > > rest of the application, was quite a drag.
> > > I've been using IMAP+ with no issues since Evo supported it (I don't
> > > even remember which version that was), so it shouldn't be a problem,
> > > always assuming the server implements it correctly of course.
> >
> > Ditto.  I've been using IMAP+ exclusively since Evolution added support
> > for it.  I have never had any related issues or lost any message; and I
> > use Evolution all day every day.
Thanks for all the replies.  I went to back to IMAP+.  However, it still
seems to be doing big downloads.  I noticed this the first time I
switched to IMAP+: at first it was very speedy, without downloading
much.  Then it seemed to start behaving like the vanilla IMAP.  Is it
possible that switching the receiver type in place (that is, in an
existing account) is leaving the old one, or parts of it, hanging
around?

Specifically, the problem is that when I switch to a big folder, even
one visited a few minutes before, evo goes through a long period of
waiting and then downloading; the time it spends downloading, judging
from the network monitor, seems about the same as it was with IMAP: 20
seconds.

I have exited and restarted evo, as that seemed necessary for the
changes to take effect.
> As Patrick says, if your IMAP server is working properly, there should
> not be any need for Evo to download all the message summaries every time
> it connects, unless somehow your local cache is getting deleted.  IMAP
> assigns a monotonically increasing message ID to each email as it's
> received and clients have the ability (at least this is how I understand
> it: note I've never actually implemented an IMAP server or client
> myself) to request information on messages with ID's above XYZ.
I have implemented an IMAP client; your understanding is basically
correct.  There are several different ways messages can be identified.

> So the client is able to cache locally the information for older
> messages and only need to retrieve information for newer messages.
> Anyway that's how I understand it to work.
>
>
> You don't say what ISP you're using.  I've had issues with accessing
> GMail over IMAP, myself.  I don't know what their IMAP integration does
> but Evo sometimes does not notice new mail for hours (if I go to gmail
> via my browser it's always immediately visible there of course).  Other
> times it works fine.  Also access seemed very slow: I modified my GMail
> account to unsubscribe from the "All Mail" folder and that helped quite
> a bit.
The problem is with an oldish Courier server; the connection problems
are either functions of firewalling/networking perversity or some kind
of starvation on the server.  We are transitioning off it.

GMail's implementation of IMAP is somewhat idiosyncratic, and it is an
interpretive layer on top of their real mail store.  I read that in the
early days there were a lot of gaps and non-standard behavior, though I
didn't notice any a few years ago.  Well, there is non-standard
behavior, but not while doing regular IMAP.

Ross