<DKIM> maxage causes loss of local email
nicolas.s-dev at laposte.net
Wed Mar 11 11:01:07 GMT 2015
On Wed, Mar 11, 2015 at 03:23:09AM -0400, Janna Martl wrote:
> On Wed, Mar 11, 2015 at 01:50:13AM -0400, Janna Martl wrote:
> >OK, so I think I'm understanding this UID check idea: we have two
> >timezones going on; e.g. the top one represents the local messagelist,
> >containing X, Y, and W, measured in UTC, and the bottom one represents
> >the remote messagelist, containing X, Z, and W, measured in UTC -0900
> >(so "0" in the bottom timeline means "00:00 -0900" = "09:00 +0000").
> > X Y W
> >-24 0 24
> > Y Z W
> > |--------------|---------------|
> > -24 0 24
> >If we don't try to correct for timezones, each messagelist will
> >contain things > 0 (with respect to its native timezone), so
> >messagelist1 = [X,Y,W] and messagelist2 = [W]. This is bad because Y
> >will get deleted from messagelist1. However, this is the only thing
> >that can go wrong. Create a (maxage + 1) messagelist for the bottom
> >that contains time > -24, and delete anything from messagelist1 that
> >is on this expanded list but not in messagelist2. Do the same in the
> >opposite direction, because we don't know a priori which direction the
> >shift is in. I really like this -- it's so much less messy than what I
> >was trying to do.
Good. That was exactly my point (while mine was broken and much less
Don't forget the case where there is no Y. This is true at the first run
and if user didn't have mail for a long time enough (> maxage).
> The downside, though, is that asking both for messages within maxage
> and messages within (maxage + 1) means that you're doing two
> searches instead of (previously) one;
No, you don't have to. Only request for (maxage + 1) ONCE. Everything
after is "just" local computation.
> if this is done for both local
> and remote, you're doing two IMAP search queries, and that takes
> nontrivial time.
More information about the OfflineIMAP-project