<DKIM> maxage causes loss of local email

[Nicolas Sebrecht]

On Tue, Mar 03, 2015 at 10:36:02AM +0100, Sebastian Spaeth wrote:

> Sorry, for popping in late. Just from memory. The time stamp of a mail
> is supposed to be equivalent on the server and on the local maildir. It
> is not supposed to be the download date, but is set to the date of the
> mail message, if I remember correctly (without having looked at the
> code).

This is correct.

>        So it should not happen that we have an older timestamp on either
> the server or the local message, right?

Well, "older timestamp" is changing from day to day in the sense of maxage.

- today is t0:
  - download mails with date >= (t0 - maxage)

- today is t1 with t1 = t0 + n days:
  - download mails with date >= (t1 - maxage)
                        date >= (t0 + n - maxage)

  - mails deleted locally are in the range:
   [(t0 - maxage)..(t1 - maxage)] = [(t0 - maxage)..(t0 - maxage + n)]

> Again, this is just from memory. Sorry, if I am wrong.

It looks like it fails because (sometimes ?) OfflineIMAP builds the
local mails list without honoring maxage. I think that's the root cause.

So, in folder/Maildir.py we set the timestamp with

  def savemessage(self, uid, content, flags, rtime):
      <...>
      if rtime != None:
          os.utime(os.path.join(self.getfullname(), tmpname), (rtime, rtime))
      <...>

And we honor maxage in _scanfolder() with:

  def _scanfolder(self):
      <...>
      for dirannex, filename in files:
          <...>
          if maxage and not self._iswithinmaxage(filename, maxage):
              continue
          <...>


Janna, could you confirm that maxage is honored for you and that
_scanfolder() excludes mails from your Maildir?

I wonder if the timestamps are actually written to the filesystem.
Perhaps it's mounted with noatime?

Could it be that the time reference is not the same for the local
Maildir and the server (UTC, ...)?

Other ideas?

-- 
Nicolas Sebrecht