maxage causes loss of local email

[Nicolas Sebrecht]

On Sun, Mar 22, 2015 at 11:25:24AM +0100, Nicolas Sebrecht wrote:

> Good catch!

Now that we talked about the L back in time case, there is another
tricky case we won't fix it might worth to be aware of.

If message M is like L, UID unkown but newer time T, it might temporary
put put the scan into a bad state, returning a wrong list.

1. M is downloaded behind OfflineIMAP's back. UID unkown, time T within
   maxage range. Sync, M get assigned a new UID = V on remote.

2. Second sync, M is rewritten with new UID V, time T.

3. Third sync at t3, if we are unlucky, M is taken as reference for
   uid_min while the UID V is bigger than it should be regarding other
   messages with time within maxage and UID < V.

4. Another sync at t4, M is no longer the UID cursor. Messages wrongly
   excluded at t3 are now synced, back to normal. BUT messages wrongly
   excluded at t3 AND not anymore within the current maxage range gets
   never synced.


So, the more there's time between t3 and t4, the more there are messages
that won't be synced while they should have be.

These are strong edge-cases because it becomes hurting only if:

- some messages must be copied out of OfflineIMAP;
- copied messages are taken as reference;
and
- there was a long time between t3 and t4.

That being said, we should document how it's bad to copy messages out of
OfflineIMAP with maxage enabled.

-- 
Nicolas Sebrecht