<DKIM> maxage causes loss of local email

[Nicolas Sebrecht]

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
well-written). :-)

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.

What?

-- 
Nicolas Sebrecht