<DKIM> maxage causes loss of local email

[Nicolas Sebrecht]

On Thu, Mar 05, 2015 at 02:58:55PM -0500, Janna Martl wrote:

>                                                Is there other
> information you wanted?

No, Gmail is the exception of the rule. It's fine!

> Given that, I'm confused by this
>     rtime = imaplibutil.Internaldate2epoch(messagestr)
> in that function: Internaldate2epoch() tries to parse the messagestr
> for things that look like dates.
> 
> >So, we also have to understand why this rtime get ignored.
> 
> I think this whole business about rtime is a distraction from the
> original problem I brought up, namely

Yes, rtime was basically designed to set the ctime/mtime of the files.

> 
> >>             But if offlineimap is run again later, it uses
> >> _scanfolder() to reconstruct the local messagelist, and the only
> >> maxage-related exclusion is done via _iswithinmaxage(), which only
> >> looks at filenames.
> 
> and the fact that filenames are set using
> 
>     def new_message_filename(self, uid, flags=set()):    ...
> 
> which doesn't have anything to do with rtime. That's why I proposed
> changing this function to take rtime into account too.

Yes and no. Yes, rtime is not the culprit. But I'm not convinced we need
rtime in the filename. We already have a datetime in the filename. Why
we cannot rely on it?

The root cause sounds more to be:
- why the datetime is wrong
or
- why the exclusion computation _iswithinmaxage() is wrong

Everything to make the maxage computation is already there. This should
be fixed to get it right rather than adding another way to exclude
mails. I really don't get the point of having the same information
stored two times in different formats within the filename.

Since IMAP servers (Gmail at least) might use different times as
references for the SINCE command, I wonder if we can retrive the
reference information by IMAP... Or compute it in some hackish way.

The whole maxage feature reveals to be quiet fragile. :-/

-- 
Nicolas Sebrecht