<DKIM> [PATCH 1/2] decouple utime_from_header from rtime

[Abdó Roig-Maranges]

> But by doing so, we are also _forbidding_ the possibility to fix the
> remote INTERNALDATE (with the IMAP APPEND command) from what we've found
> in the header.

Oh, you mean that utime_from_header should also affect IMAP folders? I imagined
that this feature was intended for Maildirs. If someone has a use case for this
we can do the same on IMAP folders, it's just a few lines of code.

I think the place to test for utime_from_header is inside savemessage, even
though it means we have to repeat the check for the different folder types. It
makes things more local, and the code easier to understand.



> When rtime was introduced, it really was to fix the modification file
> times. The filename was not affected. This allowed John to feed Dovecot
> directly with the OfflineIMAP Maildir, behind Dovecot's back. Let's call
> this configuration "direct feeding".
>
> This was at the time IMAP/IMAP didn't exist, yet. Today, I think direct
> feeding configurations are just wrong and users should migrate from
> their direct feeding to IMAP/IMAP, instead. I expect there's a lot of
> direct feeding configurations out there because this is how it was
> implemented for a long time and probably what users were told to do.
>
> Since recent 25513e90387f6, Janna and me decided to put rtime
> (INTERNALDATE) in the filename rather than use the modification file
> time. But this was while fixing maxage in mind, only. By doing so, we
> ARE breaking all existing direct feeding configurations.
>
> IOW, the quick sync mode is used with WRONG assumptions of what the
> modification file time really means FOR YEARS. This was mainly not
> hurting because INTERNALDATE are always expected older than the download
> date times of a sync.
>
> What you are doing with this last hunk is not only decouple
> utime_from_header from rtime but also FIX the modification file times to
> reflect only what it should be: last modification time of the file, as
> expected for quick syncs.

Ok, I am a bit confused now. Let me ask some questions:

1. Does anyone rely on the timestamp in the filename being the same as the
   modification time? Or can we use different values in the filename and the
   modification time?

2. Is there people out there relying on doing funny things with modification
   times? You mentioned the "direct feeding", but I don't understand what they
   need and how we break it.


If the answer to question 2 above is yes, then the assumptions of those people
were not met, because due to bugs, we were not interfering with the usual file
mtimes anyways. Is this what you were saying? Then keeping not interfering with
mtimes should not be any worse for them than it has been.


I'd argue that not messing with file modification times should be what we do by
default, because I think it is what most people would expect. One thing we could
do is add a config option "utime_from", with values:

- none:    leave modification times alone (default)
- header:  use header date as modification time
- remote:  use rtime (remote time) as modification date

Would this make sense?



> Not that it's incorrect FMPOV, but:
> - the commit message should talk about that, at least;
> - we actually have to explain to the users WHY they should avoid direct
>   feeding and migrate to IMAP/IMAP configurations.

I can't write about this because I don't fully understand the direct feeding
thing.


Abdó.