<DKIM> maxage causes loss of local email

Janna Martl janna.martl109 at gmail.com
Thu Mar 12 05:00:28 GMT 2015


On Thu, Mar 12, 2015 at 01:36:45AM +0100, Nicolas Sebrecht wrote:
>local_messageslist  # ONE SCAN  for messages in range [(maxage + 1)..lastest]
>server_messageslist # ONE FETCH for messages in range [(maxage + delta + 1)..lastest]
>
>local_lowest_uid = None
># Assumed UID ordered, lowest to biggest.
>for m in local_messageslist:
>    if (maxage) < m[uid]['rtime']
>        continue
>    # Processing uids for messages > (maxage)
>    if uid in server_messageslist:
>        local_lowest_uid = local_messageslist[uid]
>        break
>
># Clean the lists for messages we should not sync.
>if local_lowest_uid != None:
>    for mlist in [local_messageslist, server_messageslist]:
>        for uid in mlist:
>            if uid > local_lowest_uid:
>                continue
>            del mlist[uid]

Oh! I thought you were talking about a slightly different strategy,
hence the confusion. However, I'm worried about the following:

(server)
   A                B  C      
 |--------------|---------------|
-24             0              24

(local)
   A                                   
          |--------------|---------------|
         -24             0              24

Now local_lowest_uid will stay undefined, the remote messagelist will
be [A,B,C], and the local messagelist will be []. This will lead to A
(and B and C) being deleted on the server, which is bad because A
actually existed locally.

The obvious way to fix this is to check the internal date, and not
delete messages on the server with internaldate < maxage. But I
thought we were trying to avoid using internaldate, and I'm not sure
why this would be better than what I was trying to do before.

Alternatively, we could get (maxage + 2) days of local messages,
exclude remote messages that fall on the (maxage + 2) local list but
not the (maxage + 1) local list, then reduce the local list to maxage
+ 1, and continue with the above procedure. Essentially this is
forcing it to look like Case 1, not Case 2.


-- J.M.




More information about the OfflineIMAP-project mailing list