<DKIM> maxage causes loss of local email

[Nicolas Sebrecht]

On Sat, Mar 07, 2015 at 04:50:33AM -0500, Janna Martl wrote:

> Commented/ reorganized as you suggested.
> 
> As for the IMAP/timezone issue, a similar issue is discussed in the
> thunderbird bug tracker here:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=886534
> 
> In the end, they're solving a different problem, but they agree that
> there is really no reliable way of guessing the IMAP server's internal
> timezone.

Good researches.

> Idea: in Base.py __syncmessagesto_delete(), check the time of each
> thing in the deletelist to make sure it's not in the "ambiguity zone"
> -- i.e. maxage +/- 1 days ago, where we can't tell if a message was
> deleted on purpose or it just failed to show up on some list because
> of timezone messiness. If it does fall into this range, then ask for
> both messagelists from maxage + 1 days ago, instead of maxage days
> ago. Now there should be enough information to determine whether the
> message was deleted on purpose or not. (Or alternatively, just be
> conservative and don't touch things in the ambiguity zone.)

Yes, that's what I had in mind while I would not go exactly this route
to implement it.

In practice, I guess that the maxage feature is used with long enough
ranges so that the ambiguity range is not much visible to the users.

So, I would start by being conservative and ignoring the ambiguity range
in order to keep things as simple as possible in the code. This will add
enough complexity for such a corner case, BTW. Also, both directions of
syncing have to take care about that.

Basically, this means that the cached/scanned messages list won't be
anymore the whole list of messages to sync. The simplest strategy I can
think of is:

1. Scan and cache messages up to maxage + 1.
2. Reduce the cache up to maxage - 1.

(2) is the sensible part. UIDs found on both caches can be kept for
syncing. UIDs found in only one side must be rejected from the cache
list to get ignored.


Whatever the implementation route is taken, the lack of good Object
Oriented code will turn it tricky. The more I think about this, the more
I think I'm going to freeze the code and roll out a new release cycle
dedicated to deep refactoring.

> (I'm not cc'ing Mike Dawson anymore because the emails are bouncing.)

Fine, I didn't notice.

> --- /usr/lib/python2.7/site-packages/offlineimap/folder/Maildir.py	2015-02-28 02:18:19.685320880 -0500
> +++ Maildir.py	2015-03-07 04:20:31.413696048 -0500

Good work! Applied locally once paths fixed to be git compatible.
Did you test this patch?

Please, send me your signed-off-by so I can merge it.

There is a little downside I didn't think about before, though. The last
downloaded mails won't anymore be the last as sorted by ls, find and
friends. If users have any kind of script that operates on the last
downloaded mails (e.g. hackish way for anti-virus/filtering processing),
such scripts will be broken.

-- 
Nicolas Sebrecht